Quality Manager
  • Как избежать неправильного оценивания проектов

    Интересно, кто платит за такое счастье? :)

  • Как избежать неправильного оценивания проектов

    Точно! Иногда выбрасывание чего-то из продукта ведет к множественным переделкам в других местах. Ибо любая система — не есть простая сумма входящих в нее компонент. Впрочем, для многих менеджеров это не вполне очевидно... )))

  • Как избежать неправильного оценивания проектов

    Вотерфол — это когда дизайн не начинается, пока не утверждены все требования, а девелопмент не стартует, пока не утвержден весь дизайн, а тестирование не начинается, пока не готов весь код. Полагаю, реально это имеет место разве что в строительстве. Где колышек в землю не вобъешь без получения разрешения землеустроительных инстанций, а строительство не начнешь, пока не будет утверждена вся проектная документация, ну а дальше — понятно, нельзя строить 5-й этаж, до того, как будет построен четвертый :) .... Для фиксед прайс имеет значение только одно — чтобы требования, определяющие объем работ, были зафиксированы вместе с договорной ценой до начала работ. Подчеркиваю — до начала работ! И всякое изменение требований после старта проекта должно приводить к пересмотру бюджета и сроков. В этом вся суть фиксед прайса. К вотерфолу это не имеет ни малейшего отношения. Тем более, что более-менее детальный WBS, из которого вытекает бюджет и цена проекта, с самого начала включает эволюционный жизненный цикл со всеми возможными вариантами максимального распараллеливания работ.

  • Как избежать неправильного оценивания проектов

    Да, слова аджайл мы тогда не знали, Дима :). Однако, было примерно так:

    1. Были алгоритмисты (очень много), которые по стандарту, придуманному программерами, рисовали алгоритмы бортовой системы управления полетом КА (космического аппарата), исходя из его предназначения. Там было все и управление ориентацией объекта и коррекция орбиты и решение множества всяких служебных задач, включая управление многочисленными системами и устройствами аппарата. Алгоритмы рисовали сверху вниз — от самых высокоуровневых (типа дистетчера задач) до самых низовых. Начинали сверху — общая логическая схема режима функциониррования системы управления, согласовывали и сразу отдавали программерам. Потом переходили к детализации и по мере готовности отдавали программерам. При необходимости корректировали общую схему режима и тут же передавали ее программерам

    2. Программеры работали параллельно с алгоритмистами. Их тоже было много. И они тоже выкатывали новые версии софта на комплексный стенд отработки практически раз в два дня. В крайнем случае — не реже раза в неделю. Новые вресии содержали пустышки в тех местах, где еще было не готово. К каждой версии прилагался список пунктов программы отработки, которые имело смысл прогонять на стенде. Здесь надо отметить, что программу отработки с описанием тест-кейсов выпускали и обновляли алгоритмисты по мере выкатывания алгоритмов. Таким образом тестировщики (испытатели) на комплексном стенде имели актуальный план действий.

    3. Задача максимум тестировщика — установить, где дефект — в алгоритме или в коде. Тестирование было автоматизировано — специальная наземная ЭВМ в соответствии с пунктами программы отработки по своим алгоритмам запускала тестовые последовательности стимулирующих воздействий на датчики или их имитаторы, снимала с борта телеметрию и сравнивала с эталонными данными. Здесь надо отметить, что алгоритмы бортовой и наземной машин проверочной машин рисовали одни и те дже алгоритмисты. Они же придумывали все возможные и невозможные тестовые ситуации и включали их программу отработки системы управления. Поскольку поначалу ничего не работало либо вообще, либо работало не так, тестировщикам приходилось отыскивать — где ошибка. После того, как определили место ошибки — дефект отписывался в бортовом журнале испытаний и на стенд вызывали виновника торжества. Если своими силами отыскать не удавалось, вызывали алгоритмиста и он в бортжурнале писывал частную методику поиска отказа или брал вопрос на проработку до конкретной даты и давал рекомендации, как проводить испытания дальше с учетом этой проблемы. Учитывая темп поступления завершенных алгоритмов и программ, а также фиксы ранее обнаруженных дефектов, реально все работали параллельно. Особо отмечу — отыскание места ошибки было обязательно. Делать обходные маневры было запрещено. Изделие с невыясненными до конца причинами отказов при испытаниях к полету не допускались.

    4. Пара слов об управлении проектом. Поскольку не только софт, но и железо для системы управления создавалось и изготавливалось на заводах параллельно, был общий сетевой график по изделию, в котором отражались обязательства многочисленных участников этого дела. Глобально было несколько клюевых вех, отражавших зрелость конечного продукта. От стендовых прототипов до финальной готовности к летным испытаниям таких этапов могло быть до десяти и больше. В конце каждого этапа выкатывался релиз полностью отработанного софта с ограниченным функционалом, необходимым для отработки задач следующего этапа. Весь функционал необходимый для летных испытаний появлялся только к финалу. Внутри каждого этапа, как я уже писал, функционал наращивался и отрабатывался инкрементально. Своего рода канбан... Надо также сказать, что вместе с софтом на комплексном стенде отрабатывалось и многочисленное железо, которое тоже делалось и доводилось до ума инкрементально от макета до пригодного к работе в условиях реального полета образца. Железо конечно релизилось реже... :)

    Ну вот как то так... Даже не знаю, ка это назвать. Могу только подчеркнуть — сотни предприятий, участвовавших в создании космической техники все работали примерно так и по такому жизненному циклу. И параллельно, не дожидаясь, когда смежник закончит свою часть. Пользовались заглушками, макетами, матмоделями, но не стояли и не ждали готовых комплектующих. Можно ли это назвать ватерфолом? Не думаю...

    И да — забыл отметить. Это был типичный Time & Material. Если где-то и было бюджетное ограничение, то ближе к пуску его все одно снимали. Премии и всякие стимулирующе-мотивирующие плюшки только росли...

  • Схватка двух ёкодзун: ITIL vs PMBoK

    Ну здесь все просто. Определитесь, зачем вам нужен CAB? Какую конкретно проблему, как Вам кажется, это может решить? Пока не ответите себе на этот вопрос, нет никакого смысла обсуждать, как оно будет сожительствовать с помянутыми подходами... :)

  • Схватка двух ёкодзун: ITIL vs PMBoK

    Тема действительно интересна. Как по мне, то если речь идет о развитии компетенции Service Management в компании, то я бы все-таки отодвинул PMBoK на второй план и сделал бы упор на ITSM (ITIL). С другой стороны, ITSM — уж очень монструозен, и если речь идет о быстром развитии компетенции с нуля или околонуля, то стоит присмотреться к вышедшей недавно модели CMMI v2.0. CMMI Institute сделал большой шаг вперед по сравнению с версией 1.3. В новой версии реально интегрированы Development, Services и Acquisition, убрано дублирование, радикально упрощен язык. Модель стала понятна не только спецам, но и бизнесменам... :) И, мне кажется, это лучше ITIL.

  • Упал еще один Boeing 737 MAX

    В полете — да. Но в данном случае ФБР и Минюст уже начали выемку документов и проверку всей процедуры прохождения сертификации 737МАХ.

  • Упал еще один Boeing 737 MAX

    Тут Вы, Евгений, не правы. Денис весьма квалифицированный пилот. И не просто пилот, а КВС-инструктор. С правом учить других. По крайней мере был таковым до ухода из Глобуса. Если кому и доверять, то только ему. Тем более, что в настоящее время он КВС как раз на 737МАХ...

    Поддержал: Alex Persidsky
  • Упал еще один Boeing 737 MAX

    В целом да, но дыра, как мне кажется, в другом. В авиации любое новое техническое решение обязательно проходит процедуру анализа возможных отказов и их последствий. Это часть сертификации, выполняемая еще до того, как техническое решение реализуется в железе. А дыра состояла в том, что FAA уже давно делегировала некоторые свои полномочия производителю — т.е. самому Боинга. Ссылаясь на оргомный опыт и квалификацию специалистов, отвечающих за безопасность полетов в Боинге. Потеряна независимость экспертизы...

  • Crew resource management в IT-команде, или Чему нам поучиться у пилотов

    С другой стороны, проектная деятельность в ИТ все больше и больше становится похожей на операционную :)

    Поддержал: Rustam Kyrychenko
  • Crew resource management в IT-команде, или Чему нам поучиться у пилотов

    Прекрасная статья. Сам несколько раз примерялся написать об этом, но не решился. А нас, авиаторов, в ИТ, оказывается вон сколько! :)

    Поддержал: Maksym Huz
  • Безкоштовний вебінар від Legal IT Group «GDPR. Тренди 2019»

    Молодцы! Очень профессионально.

    Поддержал: Тарасюк Антон
  • Подготовка к совещанию, или Как перестать тратить время впустую

    Полезная статья. Для всех, кто организует и проводит совещания.

  • Подготовка к совещанию, или Как перестать тратить время впустую

    Статья написана для тех, кто убежден, что суть менеджмента — в «озвучивании» и «проговаривании», а не в анализе и подготовке упревленческих решений... )

  • HR for Black list

    Господам инженерам, HR-ам и рекрутерам рекомендую внимательно ознакомиться вот с этим законом:
    zakon2.rada.gov.ua/laws/show/2297-17
    При наличии толкового юриста, кто-то может сильно погореть. На деньги...