Читать книгу Решебник начинающего руководителя проекта - - Страница 5

Как гласит один из законов Мерфи, «все, что хорошо начинается, кончается плохо. Все, что плохо начинается, кончается еще хуже».

От правильного старта проекта зависит довольно многое. Чем лучше подумать на старте, тем меньше потом придется переделывать. Это совершенно не значит, что надо долго думать и мало делать. Делать-то как раз надо много, и с самого начала.

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

1. Опишите все, что хочет заказчик. Лучше начать с простого наброска документа от самого заказчика, которое называется первоначальным Видением. Это не Техническое задание, а именно то, как заказчик видит конечный результат. А потом его надо проговорить словами. Как раз в разговоре вы начнете понимать, что важно для заказчика и чего он хочет достичь на самом деле. Не факт, что именно это написано в Видении. Там может оказаться описание того, КАК заказчик себе представляет решение целевой бизнес-задачи. И не всегда это решение верно.

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

В этом пункте используй те же принципы, что и в главе по декомпозиции задач (см. главу «Декомпозиция задач»). На тебя будет валиться куча информации по самым разным аспектам будущего проекта: идеи по реализации, элементы обязательных требований, просьбы по процессам работы и законы, которые влияют на работу отрасли. Старайся выделять «области» будущего проекта и прописывай там каждый такой факт или требование. В первой версии области могут быть такими:

– Функции продукта.

– Техника и инфраструктура.

– Процессы совместной работы.

– Этапы, контрольные точки и дедлайны.

– Источники информации для будущего сбора требований.

– Пользователи, роли и их ограничения.

– Риски.

– Прочее.

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

2. Конкуренты продукта. Посмотри, есть ли конкуренты целевого продукта на рынке. Сядь и проанализируй их. Твоя задача – понять, что в них хорошо, а что плохо, и честно своровать хорошие идеи, пометив плохие, чтобы не вляпаться. В цивилизованном мире это называется бенчмаркинг. Затем включаешь здравый смысл и дописываешь Видение так, как себе представляешь, предлагая дополнительные возможности, детали и удобные моменты. Вероятно, заказчик часть из них выкинет, но это не страшно. Ваша совместная задача – прийти к общему знаменателю в головах, зафиксированному на бумаге.

3. Границы проекта. Как только вы более или менее зафиксировали Видение, пришло время прописать Границы проекта. Это дополнительный раздел, где четко описано, что НЕ будет входить в систему и где заканчивается то, что уже описано. Чтобы не было недопонимания потом в стиле: «Я думал, раз вы делаете мостик, то и асфальтированную освещенную дорогу в 5 км к нему сделаете, а иначе как им пользоваться?» Это тоже должно входить в полный вариант Видения. Или следует четко прописать, что никаких подъездных путей и освещения в конечном результате не предусмотрено.

В этой части важно еще описать, что дополнительно будет поставляться в рамках результата проекта – документация (в каком виде и какого объема?), дополнительные материалы, дополнительные работы в виде обучения, маркетинга, поддержки и т. д. Или не будут поставляться. Здесь нет задачи от чего-то сразу отказаться. Тут задача – максимально четко прописать границы. Вот и прописывай. Чем лучше пропишешь, тем меньше надо будет доделывать по завершении проекта и тем более счастливыми будут все участники.

4. Требования. Теперь уже можно писать Техническое задание (оно же – Требования). Хотя бы верхнего уровня. Берете Видение + Границы, разбиваете на сценарии и бизнес-кейсы и начинаете прорабатывать каждый в отдельности. Как проработали, прикидывайте архитектурную, техническую, интеграционную, инфраструктурную и все остальные стороны. На этом этапе необходимо продумать и описать все, включая такие очевидные вещи, как, например, авторизация, восстановление пароля, управление пользователями, уведомления и т. д. Потом надо будет оценивать, как эти задачи влияют на трудозатраты и сроки реализации.

Глубина и структура ТЗ определяется тобой (ТЗ – это текстовая модель результата. Выше мы писали про роли аналитиков-проектировщиков и про то, что глубина их участия в разных проектах разная). Есть, конечно, различные стандарты, но лучше ориентироваться опять же на здравый смысл. ТЗ должно быть понятным, должно описывать, что и как надо сделать. Больше его расписывать, если нет специальных требований заказчика, смысла нет. Если только в качестве упражнения в стиле «А жахну-ка я ТЗ по ГОСТ 34.602—89», но это уже на любителя.

5. Технологии. Пока вы описывали Требования, как система должна работать, что включать, что не включать и т. д., дальше надо договориться о технологиях создания. Вы оба (заказчик и команда) уверены, что понимаете, как надо. Только в понимании проектной команды и заказчика могут присутствовать разные технологии. Если два этих списка технологий более или менее сошлись – прекрасно. Если нет, надо договариваться. Делать все на старых технологиях – не вариант, но и совсем все новое, скорее всего, тоже не получится протащить. Тут нужен разумный компромисс – то, что без особых проблем «встанет» у заказчика, и то, на чем можно вести разработку на современном уровне.

6. Установочная встреча (она же kick-off meeting). Это неформальная встреча с участием заказчика, руководителя проекта и команды. Ее можно провести раньше официального старта работ или чуть позже. У нее нет протокола или обязательных составных частей. Это, скорее, ознакомительная и вдохновляющая встреча. Команда видит заказчика, заказчик видит команду и может услышать каждого. Заказчик обычно рассказывает о своей бизнес-задаче, цели проекта, уже плюс-минус согласованном с менеджером Видении, границах проекта и подходах. PM (Project Manager – ты) может рассказать про подходы к реализации, о технологиях и команде. Именно в этот момент проясняются ваши ожидания друг от друга, в этот же момент возникают вопросы и предложения, которые могут сфокусировать конечный продукт или прояснить новые риски. На встрече заказчик «вливается» в команду, появляются общие цели и ожидания. И это хорошо.

7. Minimal Viable Product (он же MVP). Выделите с командой и заказчиком основные этапы и MVP, т. е. минимальный кусок системы, который покажет основной процесс или его часть. Потом это будете развивать. Вам результат нужен как можно раньше, чтобы проверить вашу идею и видение конечного результата. Есть миллион причин, почему проект может не взлететь. И половину этих проблем тебе придется решить в виде задач как раз при создании MVP.

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

При выпуске MVP вы мало того что предоставите заказчику то, что уже можно использовать, так вы уже будете знать, что дальше делать (у вас есть ТЗ) и как (все мутные технические вопросы вы решили уже на этапе MVP).

8. Оценка трудозатрат. Теперь MVP надо оценить. В виде задач верхнего уровня, которые вы постепенно детализируете до конкретных понятных атомарных (малых) задач. Желательно, чтобы оценка каждой задачи не превышала 1—3 дня работы. Вы получаете структурированный план работ и Трудозатраты.

9. Ресурсы. Следующим шагом табличку с планом нужно обогатить информацией о том, кто и когда сделает эту задачу. Для каждой задачи укажите ответственного за выполнение, плановое время работы (хотя бы ориентировочно это может оценить сам ответственный) и дату, когда она должна быть сделана. Для MVP это надо сделать обязательно. В будущем можно будет там же отслеживать статус: взято в работу, сделано, отложено на столько-то. В отдельной колонке укажешь комментарии.

10. Дорожная карта. Детальные оценки на MVP и экспертные (на остальные этапы) лягут в основу верхнеуровневой Дорожной карты. Нарисуйте линейку и на нее нанесите результаты, когда и что будет. Или под ней укажите, когда начнутся и закончатся этапы. Масштаб линейки и цена ее деления зависит от величины проекта. Обычно таймлайн – от недели до квартала. При проектах больше 2 лет их разбивают на отдельные проекты и объединяют их в связанную программу. Но пока это вам не грозит. Так что берите и верстайте Дорожную карту.

Таким образом, уже на старте ты четко определишь, что такое результат, как к нему прийти и сколько это займет. А в рамках MVP ты отработаешь основные проектные процессы и снизишь проектные риски.

Все, ты все хорошо проработала на старте проекта. Выходи на штатную работу и двигайся к результату.