21 правило успешной реализации IT-проектов любой сложности и масштаба

За более чем 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 обеспечивает одно важное обстоятельство: у каждого на проекте должны быть обязанности. Обязанности обязательны, иначе это игра в одни ворота с уже напечатанном счетом на табло. Как ни странно, синергию обеспечивают именно обязанности, а не права.

Читайте также: