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

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

Расскажите коллегам:
Комментарии
Аналитик, Москва
Юрий Волщуков пишет:
Реализовав один проект, такая организация пытается продавать свои услуги многим другим, считая что она профи теперь в аналогичных запросах.
И начинается внутренняя путаница (отсутствие системности) при решении организационных и технических вопросов. 

Вы абсолютно правы! Эта ситуация настолько повторяющаяся, что становится классикой!

Николай Сычев пишет:
Анатолий Курочкин пишет:
Статья супер! Но что-то ты Герасим не договариваешь.

А по этой теме вообще возможно всё в одной статье сказать?

Всё не расскажешь. Но если отойти от не самой креативной привычки писать что-то вроде "Как стать миллионером за 5 шагов", то можно выделть главное, расставить приоритеты. 
Юрий Волощуков прав. Предполагаю, что автор именно в таком положении. Повторюсь, чтоб кто-то не искал мои предыдущие ответы: статья превоходная, написана отличным языком. Очень хочется обсудить эту тему. Ну надоело про веды, про персонал, про маркетологов.

Вот читаю:

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

Очень спорный вывод. В нормальных проектах у нормального внешнего заказчика всегда обследование и описание стоит на первом месте. На его основе частично рождается ТЗ. Без ТЗ не будет контракта. Очень часто уже и документация по первому этапу. И уж потом начинается разработка. 

С внутренним заказчиком может существовать такая проблема. Её надо жёстко ломать. Ломать через генерального. Да, бывало, что мы требовали с внутренних заказчиков и пользователей обязательной письменной заявки на тот, или иной функционал. Они возмущались, ругались. Мы терпели - если человек не сможет письменно выразить свои пожелания, то мы не сможем сделать это так, как он хочет. 

Консультант, Новосибирск
Анатолий Курочкин пишет:
чаще всего проекты выполняются без описаний бизнес-процессов, поэтому заручайтесь поддержкой бизнес-аналитиков и делегируйте им создание карт местности, по возможности с первого дня.
Очень спорный вывод. В нормальных проектах у нормального внешнего заказчика всегда обследование и описание стоит на первом месте. На его основе частично рождается ТЗ. Без ТЗ не будет контракта. Очень часто уже и документация по первому этапу. И уж потом начинается разработка. 
С внутренним заказчиком может существовать такая проблема. Её надо жёстко ломать. Ломать через генерального. Да, бывало, что мы требовали с внутренних заказчиков и пользователей обязательной письменной заявки на тот, или иной функционал. Они возмущались, ругались. Мы терпели - если человек не сможет письменно выразить свои пожелания, то мы не сможем сделать это так, как он хочет. 

По-видимому, у разных людей разные методы работы, и генеральные разные, и т.д. и т.п.

Генеральный директор, Москва
Николай Сычев пишет:
Авторы иногда забывают описать контекст происходящего, того, про что они пишут статью, так бывает, сам иногда забываю.

Да, возможно. Не только контекст, но и логику.

Аналитик, Москва
Николай Сычев пишет:
Анатолий Курочкин пишет:
Очень спорный вывод. В нормальных проектах у нормального внешнего заказчика всегда обследование и описание стоит на первом месте. На его основе частично рождается ТЗ. Без ТЗ не будет контракта. Очень часто уже и документация по первому этапу. И уж потом начинается разработка. 
С внутренним заказчиком может существовать такая проблема. Её надо жёстко ломать. Ломать через генерального. Да, бывало, что мы требовали с внутренних заказчиков и пользователей обязательной письменной заявки на тот, или иной функционал. Они возмущались, ругались. Мы терпели - если человек не сможет письменно выразить свои пожелания, то мы не сможем сделать это так, как он хочет. 

По-видимому, у разных людей разные методы работы, и генеральные разные, и т.д. и т.п.

Методик не так уж и много. Практика может отличаться, свои детали и тонкости. Это довольно хорошо известно. Есть краеугольные вещи, например, без поддержки генерального ничего не получится.

Генеральный директор, Москва
Анатолий Курочкин пишет:
У меня тоже возник вопрос про заказчика. Если это внешний заказчик, то почему возникают вопросы про документирование? А где же документация по проекту? Где техпис, нормоконтроль? Даже наличие тестировщика ставится под сомнение. Ни слова о техзадании. А ведь битва начинается именно на этапе ТЗ. Именно там половина будущих проблем. 

Неформал? Но в таком случае нельзя говорить об успехе.

IT-менеджер, Москва

Коллеги, всем большое спасибо за мнение.
Вижу эта тема у Вас вызывает живой интерес, как и у меня.

Моя цель была поделиться приемами, которые я использовал на проектах.
Проекты были разные, как внутренние - Заказчик подразделение, так и внешние - другие юрлица по отношению к компании исполнителю.
Естественно, мои проекты связаны с ИТ, в основном разработка и внедрение информационных систем.

 

По БЮДЖЕТУ
Я избежал здесь темы бюджета проекта, у меня нет серебряной пули для этого, простите.

 

По ДИЗАЙНУ
Когда я поднимаю тему дизайна - я имею ввиду не рисование интерфейса, а продумывание работы в системе.
Excel - самый гибкий инструмент, но очень вредный, т.к. скрывает часть бизнес-процессов.

Хороший дизайнер просто обязан ставить себя на место пользователя и понимать, почему тот использует Excel, а не его супер-крутой интерфейс.

Про упоминания важности коммуникаций - низкий поклон.

Еще раз спасибо!

Генеральный директор, Москва
Антон Куракин пишет:
Моя цель была поделиться приемами, которые я использовал на проектах.

Спасибо. Попытка засчитана.

Осталось сравнить эту цель с заголовком: 

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

Как бы Вы сами назвали публикацию?

IT-менеджер, Москва
Евгений Равич пишет:
Антон Куракин пишет:
Моя цель была поделиться приемами, которые я использовал на проектах.

Спасибо. Попытка засчитана.

Осталось сравнить эту цель с заголовком: 

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

Как бы Вы сами назвали публикацию?

Евгений, спасибо!

Рабочим названием было:

Играем в "..." с IT проектами, моя 21 "серебряная пуля".

Не уверен, можно ли упоминать название карточных игр в ковычках, но думаю вы догадываетесь. Из разряда свой лунапарк с .... (можно погуглить)

 

Коммерческий директор, Воронеж

Не совсем понятно, что автор имел под термином : разработчик. Вся команда – это разработчики. Но, следует выделить самого главного, это Постановщик Задач. Это человек, который хорошо разбирается в бизнесе заказчика и говорит с ним на одном языке. Формализует пожелания Заказчика и адаптирует к программно-техническому  комплексу. Если, у вас есть такой человек, то дело в ШЛЯПЕ. Программистов, системщиков, аппаратчиков найди можно, но, эти – единичной экземпляр.

Руководитель, Москва
Сергей Махлай пишет:
Хотел бы верить, что мы в комментариях все же не докапываемся, а выступаем неким альтер эго автора и способствуем в итоге совершенствованию его творения. Практически работаем тестировщиками. Причем - бескорыстно!

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

Отсюда некоторая горечь в предисловии к моему комментарию выше ) Так-то я согласен с Вами полностью

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Сколько компании тратят на обучение топ-менеджеров

Треть компаний выделяют на обучение одного топ-менеджера от 500 тыс. руб. в год.

56% россиян поддерживают наем сотрудников с ограниченными возможностями

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

Россияне назвали главные причины для увольнения

Топ причин для увольнения у опрошенных в возрасте 18-34 лет отличается от респондентов, которым 35-49 лет.

10% программистов крупных IT-компаний ничего не делают

По данным исследования, столько разработчиков лишь числятся в штате и получают зарплату, но при этом не приносят пользу компании.