Процесс

Формальный документ, которым запрашивают изменение объёма работ, сроков, бюджета или других параметров проекта.

Набор практик управления IT-услугами: как проектировать, предоставлять и улучшать сервисы, которые IT-подразделение даёт бизнесу.

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

Документирование уроков, извлечённых из проекта — что сработало, что нет, что улучшить в следующих.

Процесс изучения проблемы и проверки идей до начала разработки — чтобы строить «правильный» продукт.

Визуализация шагов процесса на схеме: обзорная карта SIPOC, подробная блок-схема и схема с дорожками по ролям и подразделениям.

Минималистичный метод управления проектами: набор коротких управленческих действий, разложенных по месячному, недельному и дневному циклам.

Контрольная точка между фазами проекта, на которой проверяется соответствие критериям перед переходом дальше.

Распределение людей, оборудования и других ресурсов между задачами проекта по времени.

Способ писать код, при котором сначала появляется падающий тест, потом минимальный код для его прохождения, потом уборка.

Примеры применения каскадной модели в строительстве, производстве и регулируемой IT-разработке с разбором фаз, рисков и сравнением с Agile.

Крайний срок с последствиями за нарушение — штраф, потеря клиента, упущенное окно — в отличие от гибкого обычного срока.

Первая фаза жизненного цикла проекта: идея превращается в формально одобренный замысел с зафиксированными целями, границами, ролями и ресурсами.

Система фиксации фактически отработанного времени, когда у сотрудников нет единого расписания старта и финиша.

Каскадная модель — линейный подход к разработке, где каждая фаза (требования, дизайн, реализация, тестирование, внедрение, поддержка) стартует только после формального закрытия предыдущей.

Практика, при которой изменения от всех разработчиков попадают в общую ветку по нескольку раз в день и каждый раз автоматически собираются и проверяются тестами.

Эвристика GTD: если действие занимает менее 2 минут, сделай его сразу — организационные расходы на запись и планирование обойдутся дороже.

Планирование, при котором каждая задача получает конкретный отрезок в календаре, и день собирается из блоков вместо плоского списка дел.

Двое разработчиков пишут один код на одном рабочем месте: один набирает, второй следит за направлением, роли регулярно меняются.

Цикл проверки гипотез из Lean Startup: собрать минимальную версию, снять данные о поведении пользователей, сделать вывод и начать следующий виток.

Изменение внутреннего устройства кода без изменения его поведения: код становится понятнее и дешевле в правке, а результат работы остаётся прежним.

Режим работы, при котором часть дня обязательна для всех (core hours), а остальное время сотрудник выбирает сам в установленных окнах.