Политика конфиденциальности cdoonline.ru
ИТ-проект сдан, а пользы нет: от чего зависит исход
Провал редко начинается с технологии. Он начинается там, где в проект взяли задачу, которую никто толком не сформулировал, — и с тех пор сроки «немного» съезжают, а бюджет «незначительно» растёт. Проектом я управляю в трёх контурах, и все три видны заказчику с первого дня: Границы: что делаем и по чему узнаем об успехе. До старта фиксируем бизнес-задачу и критерий её решения — в деньгах, сроках или снятом риске. Если задача не формулируется в таких категориях, проект рано начинать: лучше честно дождаться, пока появится. Риски: что может пойти не так и кто это закрывает. Реестр рисков живёт вместе с проектом. У каждого риска — владелец, вероятность и заранее согласованная реакция. Это скучнее героического тушения пожаров и заметно дешевле. Изменения: переход, а не только внедрение. Внедрение заканчивается не актом, а тем, что старый способ работы отключён и никто по нему не скучает. Поэтому обучение, регламенты и отказ от «как раньше» планируются с той же тщательностью, что и техническая часть. Что это даёт бизнесу. Предсказуемые сроки и бюджет; решения, которыми действительно пользуются; понятную цену остановки проекта до того, как в него вложены деньги.
Технологию выбирают по задаче: как не заплатить за моду и зависимость от поставщика
Почти любое ИТ-решение можно красиво защитить на презентации. Настоящий вопрос в другом: во что оно обойдётся через три года и можно ли будет от него уйти, если задача изменится. Инженерное прошлое нужно мне ровно для трёх вещей: Слышать, где поставщик говорит правду. Оценка предложения — не про «нравится / не нравится», а про то, выдержит ли решение нагрузку, интеграции и эксплуатацию. Технические детали за красивым слайдом видны сразу. Считать полную стоимость. Лицензия — это начало расходов. Архитектура, миграция, обучение, поддержка и привязка к вендору — вот где живёт настоящая цифра. Уметь сказать «нам это не нужно». Отказ от модного решения часто экономит компании больше, чем самое удачное внедрение. Что это даёт бизнесу. Меньше технологий ради технологий; решения, за которые можно ручаться перед советом директоров; аргументы, понятные и техникам, и финансистам.
Причину, а не симптом: как данные помогают решить проблему с первого раза
Аналитика · 2 мин «Система тормозит», «ИТ медленно отвечает», «нужны ещё люди и ещё лицензии». За такими формулировками почти всегда стоит одна конкретная причина — просто её никто не искал аккуратно. С данными я работаю как инженер, а не как комментатор. Порядок всегда один: Фиксируем метрику. Спор о проблеме начинается с согласия, чем мы её измеряем. Пока метрики нет, «тормозит» означает всё что угодно. Отделяем факт от вывода. Отчёт показывает, что произошло. Почему — надо проверить, а не догадаться. Находим узкое место. В любой системе есть звено, улучшение которого даёт максимальный эффект. Остальное — шум, за который платят деньгами. Проверяем дёшево. Маленький замер на одной выборке даёт ответ за дни, а не за квартал, и не требует проекта. Отдельная привычка — непрерывно учиться: инструменты данных меняются быстрее, чем успевает переписать регламенты. Что это даёт бизнесу. Решения опираются на данные не в презентации, а в ежедневной работе; проблемы перестают возвращаться, потому что лечат причину.