ИТ-проект сдан, а пользы нет: от чего зависит исход

Провал редко начинается с технологии. Он начинается там, где в проект взяли задачу, которую никто толком не сформулировал, — и с тех пор сроки «немного» съезжают, а бюджет «незначительно» растёт.

Проектом я управляю в трёх контурах, и все три видны заказчику с первого дня:

  • Границы: что делаем и по чему узнаем об успехе. До старта фиксируем бизнес-задачу и критерий её решения — в деньгах, сроках или снятом риске. Если задача не формулируется в таких категориях, проект рано начинать: лучше честно дождаться, пока появится.
  • Риски: что может пойти не так и кто это закрывает. Реестр рисков живёт вместе с проектом. У каждого риска — владелец, вероятность и заранее согласованная реакция. Это скучнее героического тушения пожаров и заметно дешевле.
  • Изменения: переход, а не только внедрение. Внедрение заканчивается не актом, а тем, что старый способ работы отключён и никто по нему не скучает. Поэтому обучение, регламенты и отказ от «как раньше» планируются с той же тщательностью, что и техническая часть.
  • Что это даёт бизнесу. Предсказуемые сроки и бюджет; решения, которыми действительно пользуются; понятную цену остановки проекта до того, как в него вложены деньги.

Технологию выбирают по задаче: как не заплатить за моду и зависимость от поставщика

Почти любое ИТ-решение можно красиво защитить на презентации. Настоящий вопрос в другом: во что оно обойдётся через три года и можно ли будет от него уйти, если задача изменится.

Инженерное прошлое нужно мне ровно для трёх вещей:

  • Слышать, где поставщик говорит правду. Оценка предложения — не про «нравится / не нравится», а про то, выдержит ли решение нагрузку, интеграции и эксплуатацию. Технические детали за красивым слайдом видны сразу.
  • Считать полную стоимость. Лицензия — это начало расходов. Архитектура, миграция, обучение, поддержка и привязка к вендору — вот где живёт настоящая цифра.
  • Уметь сказать «нам это не нужно». Отказ от модного решения часто экономит компании больше, чем самое удачное внедрение.

Что это даёт бизнесу. Меньше технологий ради технологий; решения, за которые можно ручаться перед советом директоров; аргументы, понятные и техникам, и финансистам.

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

Аналитика · 2 мин

«Система тормозит», «ИТ медленно отвечает», «нужны ещё люди и ещё лицензии». За такими формулировками почти всегда стоит одна конкретная причина — просто её никто не искал аккуратно.

С данными я работаю как инженер, а не как комментатор. Порядок всегда один:

  1. Фиксируем метрику. Спор о проблеме начинается с согласия, чем мы её измеряем. Пока метрики нет, «тормозит» означает всё что угодно.
  2. Отделяем факт от вывода. Отчёт показывает, что произошло. Почему — надо проверить, а не догадаться.
  3. Находим узкое место. В любой системе есть звено, улучшение которого даёт максимальный эффект. Остальное — шум, за который платят деньгами.
  4. Проверяем дёшево. Маленький замер на одной выборке даёт ответ за дни, а не за квартал, и не требует проекта.

Отдельная привычка — непрерывно учиться: инструменты данных меняются быстрее, чем успевает переписать регламенты.

Что это даёт бизнесу. Решения опираются на данные не в презентации, а в ежедневной работе; проблемы перестают возвращаться, потому что лечат причину.