Владимир Завертайлов - Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий

Или, допустим, заказная разработка. Product Owner на стороне клиента есть. Как-то на одной из встреч представитель клиента сказал на полном серьезе: «Да, у нас есть Product Owner, их целых 5» (ой!).

Что ожидается со стороны подрядчика? Что будет кто-то ответственный за проект, с кем можно вопросы порешать. А то и вовсе Proxy-Product-Owner нужен, который за заказчика все порешает, всю обратную связь со всех этих пяти Product Owner (корректнее называть их стейкхолдерами) соберет, решит противоречия и в случае чего – по башке получит. П – перспективы…

Менеджер делает все то, что нужно делать, но что не делает никто другой.

Или, как минимум, организует и делегирует, чтобы делалось все то, что почему-то никто не делает.

Но вот команда взрослеет, Scrum уже отлажен, все привыкли друг к другу и процессу, есть внутрикомандный scrum-мастер. В этом случае роль менеджера действительно уменьшается. И во что он трансформируется – вопрос на вырост. Может, в скрам-мастера. А может, в продуктового менеджера, или аналитика, или помощника Product Owner.

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

Можно ли совмещать в себе несколько ролей сразу? Быть и скрам-мастером и Product Owner? Технически – да, я такое видел в молодых командах. Но это антагонистические роли. В них специально зашит конфликт. Product Owner хочет больше и быстрее от команды, и менять все в любой момент. Scrum Master хочет, чтобы команда спокойно работала, и процесс не ломался. Сможете вы такое в своей голове удержать (быть и добрым, и злым), или начнет шизофрения развиваться? Хорошего-то мало. Я бы начал выращивать scrum-мастера внутри команды. Благо – это несложно, дня за три можно справиться.

Обычно нужно несколько спринтов, чтобы получился MVP (minimum viable product) – минимальный жизнеспособный продукт. MVP должен быть клевенький.

Цепкий, энергичный менеджер может организовать параллельную работу над аналитикой, дизайном и кодом. В Scrum-е спринт по аналитике запускаем чуть заранее. За ним – дизайн. И далее уже код. Примерно по такой схеме (правда не факт, что у вас будет так много дизайна и аналитики, но вдруг?).

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

Agile-манифест (которому сто лет в обед) – набор правильных лозунгов, которые как-то надо адаптировать к практике:

Люди и взаимодействиеважнее процессов и инструментов.

Работающий продуктважнее исчерпывающей документации.

Сотрудничество с заказчикомважнее согласования условий контракта.

Готовность к изменениямважнее следования первоначальному плану.

То есть, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева.

Agile-манифест разработки программного обеспечения. 2001 год.

В зрелом продукте документация нужна, Agile это не отрицает. В небольших web-проектах и приложениях – можно и без нее. Степень замороченности прямо пропорциональна объему проекта, педантизму заказчика и ресурсам. Правда, документация всегда немного отстает от реальности, и это окей.

Работая над SingularityApp , например, я беру какую-то крупную хотелку из бэклога и расписываю, как бы я хотел, чтобы она работала с точки зрения пользователя. Это просто схемки интерфейсов на iPad, скриншоты похожих реализаций и немного текста. Если нужно докрутить формальности – отдаю аналитикам (с проверкой, чтобы не исказили идею). Там уже могут появляться прототипы, описание граничных случаев, интеграционные протоколы и так далее, если мне нужна такая степень проработки и формализма. Такие штуки удобно хранить в Confluence или википедии проекта . Подойдет и Google Docs.

Уже эти постановки дербанятся на технические тикеты (sprint backlog), и по ним рисуются интерфейсы. Confluence позволяет отправлять задачи в бэклог прямо из текста документов (правда, довольно коряво, но все же). Мелкие хотелки из бэклога можно так детально не разжевывать.

Кодерская и техническая документация, в основном, лежит либо в самом коде (the code speaks), либо в вики проекта.

Общее правило – положи документацию как можно ближе к месту ее использования.

Иначе про нее забудут, забьют и потеряют. Мне лениво лезть лишний раз за кусочком текста. Я хочу все понимать здесь и сейчас.

Документацию важно увязать с тест-планами, чтобы QA не плодил свои постановки и хотелки.

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

На заказных web-проектах и мобильных приложениях такой контур слишком затратен, тут документацией должен стать сам код, бэклог, ТЗ или описания в Swagger . Хотя время от времени сложные, интеграционные моменты приходится документировать. Особенно, если реализуется API, с которым будут работать сторонние разработчики.

Документация требует времени, ресурсов, отдельного контура управления и внимания. Ну а хорошего технического писателя – днем с огнем.

Нужна ли документация на вашем проекте? Будете ли вы ее писать по ГОСТ 19 или ГОСТ 34, или стандартам ISO? Будете ли использовать UML или BDD-подход (Behavior-driven development, дословно «разработка через поведение»), язык описания сценариев Gherkin ? Вопрос, на который не надо торопиться отвечать. Делайте минимально необходимое и дополняйте по мере необходимости. Не старайтесь заранее все предусмотреть.

Однажды человек решил предусмотреть на сайте ВСЕ. ВСЕ тренды, вау-эффекты, поисковые рекомендации… да мало ли. Короче, все. Ну что б потом не переделывать. Это был очень предусмотрительный человек.

И на встречу со студией он решил прийти лично. Надел костюм. Пальто. Шляпу. Взял зонтик. Подумал и на всякий случай захватил солнцезащитные очки. Перчатки. Сотовый телефон. Две запасных батарейки. Это был очень предусмотрительный человек.

Взял пару бутербродов. Бутылку коньяка. Пачку презервативов. Хлоргексидин. Перочинный ножик. Вареных яиц. Ножовку по металлу. Бумажную карту Свердловской области. Аккуратно разложил это по карманам своей жилетки. И не надо думать, что это был какой-то уникум, типа Онотолия. Просто обычный человек, который всегда все предусматривал.