За более чем 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 обеспечивает одно важное обстоятельство: у каждого на проекте должны быть обязанности. Обязанности обязательны, иначе это игра в одни ворота с уже напечатанном счетом на табло. Как ни странно, синергию обеспечивают именно обязанности, а не права.
Читайте также:
Коллеги, на форуме не так много случаев, когда "докапываются". Но меня чаще всего удивляет реакция авторов.
Речь даже не про эту конкретную статью.
Уж не обижайтесь. Безусловно, это статья вызвала интерес по многим показателям - и актуальна, и язык хороший, и опыт автора чувствуется. Я сразу написал об этом. Но раз вызвала интерес, то появляются и вопросы. Вопросы профессиональные. Но ни ответа нет, ни даже лайка, типа "видел, прочитал".
И так очень часто бывает. Есть автор, который всех неугодных комментаторов банит. Есть авторы, которые молчат. Но уж точно, те, кто комментируют не докапываются. За редким исключением.
Да, в целом мы "выступаем неким альтер эго автора и способствуем в итоге совершенствованию его творения". Отработать хороший материал до мелочей.
По этому поводу почему-то вспомнился бородатый анекдот (увы в силу возраста у меня почти все такие)):
Два кирпича стоят на крыше здания и смотрят вниз. Один спрашивает у другого:
- Тебе какие больше нравятся - блондины, брюнеты или, может, лысые?
- Да без разницы. Главное чтобы человек хороший был.
Как говорил известный персонаж: "Других писателей у меня для вас нет". В данном случае других управленцев - это же сообщество менеджеров, надеюсь. Видимо, вполне себе репрезентативная выборка. Пока вот так. Что творится в обсуждениях в других социальных сетях - совсем караул. Пока мессенджеров не было, я был более высокого мнения о людях )))
У меня рецепт один - продолжаю пахать "свой огородик" ))
По итогу - все еще актуально - спасись сам и вокруг тебя спасутся тысячи.
Да, перемены в общении далеко не в лучшую сторону. То что лет 30 назад казалось неприличным в общении, стало обычной манерой.
Правда я замечаю у молодых людей новую тенденцию. Матерятся они очень много, конечно, ужу давным-давно не считается чем-то удивительным слышть мат от девушек в присутствии паренй и наоборот. Мат очень грязный, боевой. Но всё-таки в мессенджерах они сейчас стараются заменять мат новоязом. Например, "кринж" и все всё поняли без мата.
И ввсё-таки вы правы, общение во всех сообществах стало гораздо агрессивнее. У меня есть на это своя точка зрения, она не для этой ветки. Только намекну - дипломатия в мировой политике тоже ушла.
Я работал одно время в университете. На глазах все это зародилось и стремительно набрало серьезные обороты. Долгое время делал замечания матерящимся. Причем удалось найти удобоваримые формы, не травмирующие самооценку молодых людей. Но на определенном этапе обратная реакция часто стала настолько агрессивной, что дальше логичным продолжением была бы уже потасовка. Типа - тебе чего надо, мужик? После определенных терзаний пришлось отказаться от замечаний. Дал слабину, признаю. Но взвесив, варианты возможных последствий...
А что касается разрушения сложившейся после Второй мировой войны системы международных отношений (знаю тоже не понаслышке - давно на свете живу и доводилось активничать в разных сферах)), то абсолютно с Вами согласен - её больше нет. И как потом будем из этого выбираться, не очень понимаю.
Ну да в истории человечества ничего же нового (кроме накопленных арсеналов). Все, как обычно. Как-то будет.
Я тоже как-то скучаю по хорошим, добрым дискуссиям. Пусть даже эмоциональным.
Леонид, спасибо за комментарий.
Разработчик - это разработчик ПО, программист.
Обычно с бизнесом говорят бизнес-аналитики и РП. Но вот за 20 лет я не видел человека, способного угадывать желания, особенно будущие, заказчика. Да, требования собрать, формализовать можно, но всегда есть корнер кейсы, которые на бумаге часто не видны.
Нужно организовать управленческий батл, когда-то сидел на видосиках по теме Тарасова и управленческих поединков. Хотелось бы самому поучаствовать с кем-нибудь онлайн. Если интересно, пишите... созвонимся)
Я ни разу не встречал постановщика задачи, как отдельной роли в проекте. Хотя вариантов много. Во внутренних проектах я был много раз просто начальником департамента (назвали так, а на самомо деле там был один отдел, только работал он на разных площадках), или отдела. В задачу входиа и постановка задачи,и руководство проектом. Часто бизнес-анализ делали совместно с программистами и представителями других подразделений. ТЗ обязательно! Затем программмисты, девопс, тестировщики (во внутренних проектах часто отсутствует).
На внешних заказах всегды были в моей практике руководители проектов, а нач отдело, техдиры занимались своей работой. Часто в больших проектах роль РП разбивается на аккаун-менеджеров (общение с заказчиком) и непосредственно РП. РП может быть несколько, если проект большой и по разным направлениям, территориям. Если продукт один, а заказчиков несколько,то и каждому заказчику выделялся свой РП.
Был случай, когда РП стоял в штате заказчика. Но это не совсем порядочный, мягко говоря, вариант.
В целом я бы сказал, что распределение ролей очень важный этап. Тут надо подбирать не столько по методикам, сколько по наличию и качеству ресурсов.
Обычно это совместная работа с заказчиком до начала проекта. Со стороны и заказчика и исполнителя может быть несколько человек. То, до чего в итоге договорились, является частью контракта.
Есть обязательные роли и все остальные на усмотрение менеджера проекта. Что-то из списка согласуется с заказчиком, так как эти люди затем участвуют в согласовании документов. В больших и многоэтапных проектах могут быть достаточно сложные оргструктуры, включающие субподрядчиков.
Да, это так!
С субподрядчиками, тем более в сложно-технических проектах, например, строительство ЦОД+ПО структура может быть очень сложной.