За более чем 20 лет опыта я выработал некие «серебряные пули», которые существенно повышают шансы на успех. На каких-то проектах достаточно пары выстрелов, где-то использовал практически все – в зависимости от контекста.
В этой статье я намеренно разделяю бизнес и IT, чтобы подчеркнуть важные аспекты в рекомендациях, хотя на самом деле они не должны быть разделены.
Под бизнесом я здесь подразумеваю продажи, сервис, маркетинг и т.д., а под IT – команду разработчиков, аналитиков, бизнес-аналитиков, дизайнеров и др.
1. Business first
Во всем, что делает компания, а особенно в части проектов мы должны в первую очередь ориентироваться на бизнес. И если бы требовалось дать только одну рекомендацию, то я бы оставил эту. Поэтому бизнес является драйвером проектов.
С этим вроде все понятно, а теперь, внимание, важное утверждение: «Если бизнес не может сказать на входе, что он хочет, то, соглашаясь на проект, вы берете роль бизнеса на себя». А проекты, где IT примеряют на себя роль бизнеса, редко завершаются успехом.
И вот вы потратили еще несколько месяцев, доказывая, что хорошо разобрались в теме, «додумали за бизнес». А в итоге он считает такие проекты инородными «почему с нами не советовались?» и активно им сопротивляется.
А что же, не браться за проект? В 99% случаев – да, кроме измотанных нервов и выгорания вас и команды, вы вряд ли получите что-то адекватное на выходе, а если получите, то рискуете услышать подобные формулировки: «Не, ну это не то, что мы хотели», «Да, хотели, но не таким же образом» и т.д.
В общем – «не уверен, не обгоняй».
2. Загляните под камни
Следующим пунктом будет валидация требований бизнеса. Этот подход я называю «разобрать до винтика», то есть мы убираем всю мишуру и смотрим, а что собственно предстоит делать.
И тут нам приходит на помощь ТРИЗ (теория решения изобретательских задач) с ее базовым принципом: идеальная система – система, которой нет, но все ее функции выполняются. Иными словами, целевой функцией IT должно быть следующее – как бы сделать так, чтобы не пришлось ничего разрабатывать, но потребности бизнеса были удовлетворены.
В общем, прежде чем оголтело бежать и реализовывать требования, IT должны убедиться – нельзя ли что-то переиспользовать или реализовать на текущих решениях.
Только не предлагайте Excel, пожалуйста.
3. KISS для вас
В разработке существует замечательная методология KISS (keep it simple, stupid), принцип которой – не усложняй.
В соответствии с законами кибернетики сложные системы склонны к саморазрушению, поэтому важно создавать простые, но эффективные решения. Не выдумывайте космолеты, не перегружайте интерфейс ненужными штуками и украшательствами, стройте ровно то, что нужно, помните о ТРИЗ.
Помните – камень ломается редко.
4. Не включайте режим DRY
Упомяну еще один паттерн – DRY (Don’t repeat yourself) – не повторяй себя. Так вот, если при разработке эта методология позволяет сократить время на написание кода за счет переиспользования функций, то при реализации проекта этот паттерн сильно мешает.
Дело в том, что команда воспринимает новый проект как шанс попробовать новую технологию или инновационные решения. Это хорошо для опыта, резюме участников проекта, но вредит проекту с точки зрения сроков. Использование новых и непроверенных решений взвинчивает технические риски, вплоть до срыва, особенно все, что касается хранения данных (см. пункт 17).
Лучшая стратегия – опираться только на проверенные технологии, которые вы раньше использовали или использовал хоть кто-то из команды разработки в сопоставимых ситуациях.
В общем старый друг – лучше десяти новых.
5. Заземление спасает жизни
Под заземлением я понимаю то, что руководитель проекта не должен витать в облаках, а твердо стоять на земле двумя ногами. Во время проработки требований и концепции проекта вас могут закидать хотелками и дополнительными требованиями. Работа руководителя проектов в данном случае отделять зерна от плевел, определять критический путь.
Придется научиться говорить бизнесу «Да, но не сейчас». Однако сразу предостерегу от полного игнорирования пожеланий. Обязательно нужно их фиксировать и думать, можно ли их выполнить, попутно не влияя на основной путь.
Говоря простым языком – не стройте космические корабли, если это не ваша работа, сужайте область проекта, помните про заземление, оно действительно спасает жизни.
6. MVP
Этот пункт является логическим продолжением предыдущего – как управлять требованиями бизнеса. Все что нужно сделать – это разделять поток пожеланий от бизнеса на три категории:
- MVP (минимально жизнеспособный продукт) – то что лежит на критическом пути.
- Nice to have – то, что не лежит на критическом пути, но дает заметный профит.
- Dreams – все, что имеет нечеткие требования, не лежит на критическом пути или эффект от реализации не сформулирован или не ясен.
Важно также донести до бизнеса данную терминологию и что вы под ней понимаете, тогда и ожидания бизнеса будут выравниваться.
7. Убейте драконов
Раньше на картах неизведанные территории помечались надписью – здесь живут драконы. В нашем случае такими территориями являются бизнес-процессы. Если у вас уже есть их описание и они соответствуют реальным рабочим процессов – поздравляю, у вас есть карта местности проекта.
Но чаще всего проекты выполняются без описаний бизнес-процессов, поэтому заручайтесь поддержкой бизнес-аналитиков и делегируйте им создание карт местности, по возможности с первого дня.
Это критично для валидации требований, поиска узких мест проекта и, самое главное, – проведения приемочных испытаний (UAT).
Чем больше драконов вы разоблачите – тем лучше.
8. И этих тоже
Драконы поменьше, но намного опаснее. Бизнес-процессы – это хорошо, но описание сценариев использования системы (use cases) – бесценно. Как и предыдущим пунктом, этим желательно заниматься с первого дня проекта.
Обращайте внимание на то, как и зачем используют Excel – это затаившийся дракон.
Делегируйте это дизайнеру, тогда интерфейс получится не только красивым, но и удобным.
9. Делайте UI по Agile
Опыт показывает, что изначальные требования к UI редко соответствуют тому, что мы получаем на выходе, и тому, что реально хотят пользователи. Ведь по мере знакомства пользователей с системой возникают новые идеи в части упрощения и улучшения. Поэтому очень важно показывать пользователям даже малейшие изменения на UI как можно раньше. Перекрасили кнопку – покажите, подправили верстку – покажите.
Проектируйте интерфейс тоже сразу, как можно раньше. И показывайте пользователям его тоже – как можно раньше.
Да, и не забывайте собирать метрики по использованию UI.
10. Загляните в конец
Узнайте, какие отчеты и для кого будут нужны. В какие системы необходимо выгружать данные, кто их будет аудиторивать и каким способом.
Не забывайте про важные штуки: метрики (бизнес и технические), логи и журналы аудита.
Если у вас есть время на что-то одно, то сделайте журнал аудита и изменения данных. Это избавит вас от многочасовых препираний и разборок, которые бы решались строкой из системы – кто, когда и что изменил.
11. Сроки, такие сроки
Пожалуй, этот пункт является самым тяжелым. Не секрет, что сроки со стороны бизнеса не устраивают IT, а сроки IT – бизнес.
Общая рекомендация: закладывать сроки x1,5 для понятных требований от первоначальной оценки и x2,5 – для непонятных.
Эти цифры закладываются с учетом рисков и непредсказуемых обстоятельств. Только обязательно доведите такую арифметику до бизнеса и не пытайтесь схитрить, это чувствуется. Этого все равно часто оказывается мало, потому что люди под давлением склонны приукрашивать и занижать реальный объем задач.
Вы же, надеюсь, не верите, что люди работают (или пишут код) непрерывно 8 часов подряд, не болеют, не ходят в отпуска и не отвлекаются на другие задачи и созвоны? Нет? И я тоже.
12. Наследие
Редко проект создается в чистом поле без оглядки на текущие информационные системы и данные. Поэтому необходимо понять (чем раньше, тем лучше), что вы будете делать с историческими данными.
Стратегии тут ровно три в порядке трудоемкости:
- данные не мигрируются;
- мигрируются только итоги;
- мигрируются все исторические данные.
Когда данные не мигрируются – это замечательно в части трудоемкости, но имеет серьезный недостаток – вы не показываете, как данные, к которым привыкли пользователи, будут представлены в новой системе. Если вы заведете даже с 10 строк – это будет нерепрезентативно. Мой опыт показывает, что лучше всего договариваться на перенос итогов.
Если бизнес не хочет миграции, перенесите итоги хотя бы на тестовое окружение и покажите пользователям. Это будет лучшая демонстрация было-стало, где пользователи могут оценить все преимущества новой системы.
Да, и не забывайте, что может потребовать сосуществование и синхронизация данных с текущими системами, это часто оказывается роялем в кустах.
13. Враг у ворот
Ваш злейший враг – время. Все остальные – это недооцененные партнеры. Будьте открыты к критике, новым предложениям и незначительным изменениям требований.
Каждое проигнорированное замечание – это пункт в обвинительном заключении при провале проекта. Да и вообще, чем раньше вас «побьют», тем лучше.
14. Компромиссы
Компромиссы на проекте вечны, единственный компромисс, на который нельзя идти – качество продукта. Если в команде есть QA (тестировщики) – пишите автотесты с первой строчки кода и как можно больше.
15. Рефакторинг под запретом
У команды с первых строк кода появляется непреодолимое желание рефакторить (бесконечно улучшать) и оптимизировать решение.
Просто запрещайте и бейте по рукам. Опыт показывает, что это сказывается на сроках задач, иногда порождая новые проблемы.
16. Обрастайте союзниками
Отдайте авторство пользователям, бизнесу и стейкхолдерам. Как только участники проекта будут считать систему или проект своим детищем, а не вашим – дела пойдут значительно быстрее, ведь вы будете окружены уже не просто участниками, но и союзниками.
Откажитесь от притязаний на авторство и будете в почете. Кто проиграл – тот победил.
17. Хранение данных – это проблема
Я очень люблю повторять, что проектирование систем –это просто до тех пор, пока вам не нужно управлять данными. Это трудоемкий и дорогой процесс, поэтому проектируйте хранение данных как можно раньше и как можно тщательнее, с привлечением специалистов.
Изменения в этой части проекта – одни из самых дорогих. Нет, самые дорогие.
18. Бюрократия – друг
Понимаю, что это очень тяжело и нудно, но все же не забывайте про документацию. Держите в голове мысль: «А что, если половина исполнителей на проекте уволится, выгорит, заболеет, перейдет на другие проекты?». Порог входа в проект должен быть минимален.
Некому писать документацию – записывайте встречи и демо. Если во время проекта вы не можете сходить в отпуск – вы башня знаний и ее надо демонтировать максимально быстро.
Есть проблемы, провалы? Делитесь ими как можно скорее. Вы не один!
19. Один в поле не команда
Не стесняйтесь обращаться за помощью и делегировать как отдельные задачи, так и направления целиком. Делегировать можно как бизнесу, так и другим менеджерам проектов, аналитикам или даже ведущим разработчикам.
Команду формирует именно наделение участников правами и обязанностями перед проектом, иначе есть риск получить толпу созерцателей, где на арене великий гладиатор бьется с кучей львов и жуков (багами).
Великая ответственность рождает великую силу, не перепутайте.
20. Проблемы на проекте? Вы их еще не видели
Проблемы на проекте растут как грибы и чем дальше в лес, тем больше всякой живности. Проблемы, как и риски, можно приоритизировать, управлять ими, передать, да на худой конец, немного сдвинуть сроки проекта. Не хотелось бы, но возможно.
Реальные проблемы начинаются тогда, когда в систему заходит первый пользователь. Теперь к текущим проблемам у вас добавляется поддержка, контроль стабильности и доступности сервисов. К тому же, вам нужно будет учитывать реальные данные пользователей, их миграцию в случае изменений. К требованиям от бизнеса добавляются требования от клиентов.
Здесь лучшей стратегией будет делать ограниченный пилотный запуск (канарейка, бета-тестирование) и постепенно наращивать аудиторию до 100%.
21. Эксплуатанты – ваш туз в рукаве
Звучит нелепо, но руководители проектов, загнанные в рамки сроков, требований и бюджета, часто забивают на конечных пользователей системы. А очень зря, ведь кроме дополнительных кейсов и требований, которые упустил бизнес, пользователи способны зарубить внедрение.
Из неочевидных плюсов – если заказчик нацелен не принять проект (что бывает по разным причинам), он обычно интересуется мнением конечных пользователей в надежде, что они предоставят дополнительные негативные аргументы. Важно не что они будут говорить официально, важно, что они скажут кулуарно. Теперь заказчик находится в ситуации, где он выступает уже не против IT или конкретного руководителя проекта, а уже против потенциального эффекта, компании и фактически против себя.
Секрет прост – тесно работайте с эксплуатацией.
Вместо выводов
В заключение я бы хотел добавить, что сильная команда мотивированных людей способна вытащить даже самый безнадежный проект. И наоборот, команда незамотивированных профи часто ведет проекты под откос.
При должном уровне мотивации воронка синергии захватит весь проект и обеспечит попутный ветер в ваших парусах. Звучит красиво, а на деле – еще красивее.
И еще – синергию бизнеса и IT обеспечивает одно важное обстоятельство: у каждого на проекте должны быть обязанности. Обязанности обязательны, иначе это игра в одни ворота с уже напечатанном счетом на табло. Как ни странно, синергию обеспечивают именно обязанности, а не права.
Читайте также:
Блестяще!
Автору низкий поклон.
Очень интересная статья, спасибо, Антон! Разошлю знакомым.
Внимательно прочитал, но так и не понял - кто же заказчик у описанного и выполняемого по всем этим правилам проекта? Кто стейкхолдеры? Кем, когда и как проект документируется? Как можно было упомянуть бюджет проекта лишь однажды и через запятую?
И абзац, который поставил меня в тупик:
Никогда не видел, чтобы один менеджер проекта делегировал (!) задачи другому менеджеру проекта.
Кто-то уже понял, кому именно адресованы все эти советы и правила?
Как я понял, речь идет о разработке и внедрении ИТ-продуктов куда-либо в бизнес.
Какую-нибудь систему электронного документооборота, управленческого учета и т. д.
Конечно, автор мог бы и сам это пояснить, а то я сначала подумал, что речь идет о разработке нового ПО на продажу, но потом по контексту понял, о чем идет речь, надеюсь, что правильно понял.
А под делегированием, по-видимому, имеется в виду передача дел от ИТ-шников другим подразделениям, чтобы они тоже подключались.
"Куда-либо в бизнес" - неплохо сказано! Речь идёт только о внутренних проектах? И только о внедрении каких-то продуктов?
Пока самое главное в проекте потерялось где-то между строк. Проектов без заказчика не бывает.
Спасибо большое!
Николай, спасибо! старался
Евгений, спасибо за комментарий.
Я вначеле умышленно разделил подразделения внутри компании на бизнес и ИТ. Заказчик = собственно тот кто приходит с данным проектом и согласует его разработку в принятом флоу. Это может быть как внешний Клиент, так и внутренний. Для меня лично нет различий - все Клиенты. Обратите внимание, я эксплуатанта выделил в отдельный пункт, т.к. очень часто это разные роли. Счастье, когда это одни и теже.
Про делегирование.
На крупных проектах у вас могут быть и ассистенты и другие ПМ (младшие). К тому же есть аналитики, старшие разработчики. Если мы конечно говорим о работе в команде. Обычно, в хорошиих командах люди сами вызываются помочь.
Но знаете, что интересно - практически на любых проектах есть что делегировать.
Чтобы Вы хотели услышать по бюджету и по документации?
Да, коллеги, тут возможно еще путанница из-за смены названия. Изначально я обозначал ее как 21 "рекомендацию", которая может повысить шансы на успех
Спасибо. Давайте чуть медленнее.
Я - это кто?
Далее: у любой организации есть структура. Если Вы описываете внешние (а не только собственную) организации, то вариантов очень много. Роль IT подразделения и его обязанности различаются в зависимости от специфики бизнеса компании.
Внешний заказчик подписывает договор с юр. лицом, а не его подразделением. В договоре указываются все существенные параметры проекта, если предполагается работа в таком формате.
Что такое "принятый флоу" - поясните. Проекты какого сорта и содержания Вы обычно выполняете?
Это не могут быть те же роли в случае внешнего заказчика. Если заказчик внутренний - любые варианты, зависящие от функционала, но вряд ли это прописывается в форме договора.
Тот же вопрос: я - это кто? Менеджер проекта, отвечающий за его успех? Тогда я определяю орг.структуру проекта, план коммуникаций, зоны ответственности, исполнителей, поставщиков, субподрядчиков и пр., но это не про делегирование.
Какие в данном проекте нужны исполнители, определяется менеджером проекта. Но, еще раз, это не про делегирование. Менеджер проекта свою работу делегировать не может.
Хотя бы что-то, если не сложно. Можно начать с требований.
Бюджет согласуется с заказчиком, процесс бывает долгим. Но проектов без бюджета не бывает, как и договора.