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

Традиционный для отечественных компаний сценарий, ведущий к подобным проблемам:

Команда состоит из человека с идеей и пары-тройки разработчиков. Он придумывает и держит требования в голове, разработчики весело кодят, о документации никто особо не думает, идёт творческий процесс. В лучшем случае оставляются комментарии в коде.

Продукт усложняется, команда растёт, модулей становится всё больше. Руководитель всё ещё помнит, зачем нужен и как работает каждый кусок системы. Тимлид всё ещё держит в голове всю архитектуру приложения. Начали использовать доску задач и какие-то бесконечные экселевские файлики.

Продукт усложняется ещё больше, часть команды сменилась. Руководитель с трудом помнит корректные сценарии работы кусков системы, тимлид всё чаще отправляет с вопросами о коде к людям, этот код писавшим. Переползают на какую-нибудь систему постановки и контроля задач, потому что иначе никак. Начали потихоньку описывать модули в отдельных документах, лежащих в гуглодоках.

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

Финиш. В продукте бардак.

Бороться можно. Серебряная пуля называется: «выделяем весь консалтинг в отдельный бюджет». С ранних этапов, как бы ни хотелось окунуться в кодинг с головой, сначала проектируем, затем кодим. Произошли изменения — актуализируем документацию. Для того, чтобы не забыть, встраиваем коррекцию документации в карту контрольных проверок и не считаем функционал готовым, если документация неактуальна. Кроме того, нельзя допускать, чтобы разработчики что-либо делали без формальной задачи в системе постановки и контроля задач. Это требование менее критично, но если его не соблюдать, в дальнейшем будет очень трудно найти концы.

Данный рецепт холостяцкой кухни чрезвычайно прост, а продукт на выходе — нажорист и красив.

Понадобятся:

1. Любые макароны.
2. Сливки.
3. Бекон.
4. Помидоры.
5. Лук.
6. Специи по вкусу.

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

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

Пока макароны варятся, ставим на малый огонь сковороду, льём туда немного растительного масла (немного!) и греем. Шинкуем бекон и помидоры, режем кольцами лук. Как только сковорода немного прогреется, выкладываем на неё то, что получилось нашинковать. Обжариваем до золотистой корочки. Как только станет шипеть совсем уж сильно (через три-четыре минуты обжаривания), заливаем сливками.

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

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

Как только содержимое сковородки дойдёт до кондиции, выливаем его на макароны. Затем можно насыпать тёртого сыру и подать к столу.

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

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

Избавляемся от ненужных вещей.

Если дома накапливается ненужный, занимающий место хлам, заведите небольшую коробку и ограничьте количество хлама этой коробкой, остальное — выбросьте или подарите. В будущем в коробку можно будет класть вещи только вместо уже лежащих в пропорции 1:2. Хотите положить новую какашку — должны избавиться от двух старых.

Испытано — выкинутый хлам НИКОГДА не пригождается. Я переехал в новую квартиру из старой, десятилетиями заполняемой разнообразными вещами и взял с собой лишь те вещи, которые реально использую и их крайне мало.
 
 
============================

Закладки в браузере.

Для хранения закладок используйте ИСКЛЮЧИТЕЛЬНО панель Chrome. Туда влезает 10-12 сайтов. Хотите поставить новую, сверх лимита — придётся удалить одну старую. Если ссылка реально может пригодиться в будущем, кидайте в соответствующий блокнот эвернота, но в браузере не держите.

Испытано — 16 кнопок спид диала хватает вообще на всё, причём три-четыре пустуют. После перехода на мак, стал пользоваться панелью Safari и её же спид диалом. Ограничения работают.
 
 
Моя панель выглядит так:

 
Двух-трёх букв достаточно для идентификации сервиса.

• FD — RSS-ридер Feedly.
• BB — интернет-банк.
• GK — Google Calendar.
• EN — веб версия Evernote.
• GD — GoogleDoc
• GM — GoogleMaps
• TJ — Tjournal, весьма интересный ресурс.
• PB — Пикабу, убийца времени.
• Mtr — Метрополь, ещё один убийца времени.
• TG — Веб версия Телеграма.
• ВК — Вконтакте.
• GA — GoogleAnalytics
• ПОПСА — этот самый блог.
• GTr — гугловый переводчик.

 
 
============================

Лишний софт.

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

Испытано — я больше не боюсь кражи/выхода из строя ни ноутбуков, ни ПК и готов развернуть рабочее окружение за пятнадцать минут. Позже запилю пост об используемом ПО на работе и дома.
 
 
============================

Безбумажность.

Если у вас скапливается много бумаги, заведите папочку и ограничьте её объём 30 листами. Всё остальное мужественно сканируем, конвертируем, проставляем теги и с огромным наслаждением пропускаем бумажные версии через шрёдер. Папочка работает так же, как и коробка для хлама: хотите положить листик — должны выкинуть два имеющихся.

Не пробовал — у меня мало бумаги.

Ещё не раз и не два я напишу о ментальных картах. Это универсальный инструмент.

Конспектируем лекцию/совещание/что угодно при помощи ментальной карты.

Плюсы:
Читать потом в сто раз проще, чем линейный конспект.

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

==============
В качестве примера приведён конспект занятия клуба Agile-практиков. Тема, как видите — заказная разработка по скраму.

1. Лучше всего использовать большой лист. А4 недостаточно — посмотрите, как приходится мельчить.
2. Обязательно нужно рисовать картинки — они вызывают нужные образы быстрее, чем текстовые надписи.
3. Очень важно рисовать разными цветами, эта схема в ч/б, потому что не было под рукой цветных ручек.

— Как съесть слона, используя только нож и вилку?
— По кусочку.

Проведение больших доработок качественно отличается от мелких. Заказчик хочет здоровенный и очень сложный кусок функционала (будем называть его продуктом). Как не облажаться?

Если собрать требования ко всему продукту, сформулировать техзадание, потратить массу времени на реализацию, при сдаче выяснится, что заказчик хотел совершенно не это и нужно потратить ещё столько же времени на переделку. Разработчик и аналитик теряют впустую много времени, очевидный риск.

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

Давайте разберём контрольный пример.

Бизнес-проблема: «Для того, чтобы более эффективно продвигать и продавать наш товар (одуванчиковый лимонад), мы хотим онлайн-каталог».

Результат предварительного сбора требований:

На сайте должны быть разделы:

1. Главная страница
2. О компании
3. Каталог
4. Оплата и доставка
5. Контакты

Ключевой момент — заказчику не понадобится оформление заказа с сайта. Только онлайн-каталог и форма отправки заявки.
 
 
Хорошо. Составляем крупноуровневый план работ:

1. Разработать и согласовать концепт дизайна контентных страниц.
2. Изготовить Главную страницу.
3. Изготовить Каталог.
4. Изготовить прочие контентные страницы.

 
 
В ходе первой итерации мы будем делать концепт дизайна, а затем — Главную страницу.

Ключевой момент — на первом этапе детализируем только требования к дизайну и главной странице. Остальные пункты плана для нас как бы в тумане. Мы знаем их состав и очень примерно — какими они должны быть. Пока не нужно об этом думать — после того, как сдадим Главную страницу, желания заказчика могут смениться на диаметрально противоположные.

Итак, на первом этапе готовим для согласования документ, содержащий:

1. Детализированные требования к дизайну: корпоративные цвета, количество колонок, общий вид вёрстки блоков, шрифты, стиль иллюстраций.
2. Детализированные требования к главной странице (обязательно с wireframes), состав блоков, назначение каждого блока, порядок следования и проч.

 
 
Для остальных кусков функционала пишем требования на уровне возможностей: «Каталог позволяет просматривать карточки товаров с возможностью фильтрации, карточки содержат описания товаров и форму обратной связи». Такой детализации пока вполне достаточно.

Есть ли риски в данном случае? Увы, есть. После сдачи первой итерации требования могут измениться настолько принципиально, что результат первой итерации придётся переделать полностью. К сожалению, с этим можно бороться только уменьшением количества требований на итерацию до минимально возможного. Правда, в этом случае возрастают расходы на тестирование (короче итерации — больше регрессионных тестов в единицу времени).

Предположим, первая итерация прошла удачно. Дизайн понравился, главная страница свёрстана грамотно, замечаний немного или нет вовсе. Наши дальнейшие действия — в первую очередь, актуализация плана. Не устарели ли требования? Если всё нормально, переходим к детализации требований на вторую итерацию, иначе корректируем, пересогласовываем, переоцениваем.
 
 
Резюме:

1. Разбиваем функционал на блоки.
2. Составляем общий план.
3. Детализируем требования только к тому блоку, который пойдёт в работу в ближайшую итерацию, остальные блоки описываем на уровне возможностей.

 
 
Такой подход делает разработку предсказуемой и минимизирует риски.

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

В США продолжительное время один пациент из пяти тысяч прооперированных умирал из-за ошибки анестезиолога. Внедрение карт контрольных проверок в сочетании со стандартизацией интерфейса оборудования и сглаживанием градиента авторитета (объяснение медсёстрам, что доктор не всемогущ и если они видят ошибку, они обязаны о ней сообщить) привело к снижению смертности до одного пациента на 200-300 тысяч прооперированных (снижение смертности в сорок раз).

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

Автор работает в организации, в которой менеджер продукта выполняет не столько функции специалиста по развитию, сколько именно организационную работу и обеспечивает качество всего итеративного процесса. Выяснилось, что без карты контрольных проверок слишком легко упустить одно из мероприятий и навредить срокам выпуска версии → разозлить заказчиков, ожидающих выпуск функционала к определённой дате.

Был разработан и внедрён протокол планирования итераций, содержащий перечень мероприятий, даты, отметки о выполнении, а также фамилии сотрудников, ответственных за каждый этап. В качестве инструмента был выбран OneNote. К сожалению, протоколы проведённых итераций содержат конфиденциальную информацию, поэтому приведённый пример будет гипотетическим.

Таким образом, процесс состоит из:

1. планирования работ
2. написания требований к доработкам
3. демо требований
4. старта разработки
5. кодфриза разработки
6. регрессионного тестирования
7. съёмки ролика о новом функционале
8. передачи билда на поддержку.

 
 
Каждый из этапов состоит из группы действий, которые нужно не забыть провести. Некоторые действия (такие, как «Бэклог оформлен в TFS») являются сложными и сами состоят из групп действий, описанных в протоколах нижнего уровня.

Ответственный в данном случае — сотрудник, имеющий полномочия о принятии решения об успешном прохождении этапа. Как видно из примера, за все действия до кодфриза отвечает менеджер продукта Бычко, за выход на кодфриз — тимлид Ригельман, организацию и проведение регрессионного тестирования — глава QA Бунг и, наконец, за съёмки ролика и передачу на поддержку — глава управления продуктом Гольдштейн.

Ниже данной таблицы в протоколе располагается детализированная информация о проведении каждого из этапов. Расшаривание через OneDrive и соответствующие права доступа позволяют ответственным лицам «расписаться» о проведении этапа.

Благодаря внедрению данного протокола практически исключается пропуск любого из шагов, кроме того, все лица, желающие наблюдать за ходом итерации (CIO, глава проектного офиса, глава управления продуктом), могут это сделать, взглянув на протокол через интерфейс веб версии OneNote (или подключив блокнот в десктопной версии приложения).

Люди, ставшие менеджерами, сталкиваются с проблемой — если возникает ситуация, когда нужно лично сделать что-нибудь «руками» (написать требования, сделать презентацию), это оказывается практически невозможным — постоянно отвлекают.

К сожалению, единственное решение в данном случае — «красный флажок» и уход в автономное плаванье на несколько часов, иначе поток не создашь. Секрет в том, что не нужно стесняться использовать эту возможность.

У разных организаций разная специфика, однако опыт показывает, что есть лишь одна причина срочно отрывать менеджера — неожиданно всплывший у клиента грозный дефект ПО, который мешает ему работать. Всё остальное может потерпеть несколько часов.

По теме. Интересный пост Людвига Быстроновского о том, как всё успевать.