Дисклеймер: Сегодня мы будем говорить исключительно о неудачных проектах, поэтому не будем называть имен, паролей и явок.
Все провальные кейсы из моего и дружеского опыта можно поделить на три типа по источникам проблем:
1. Работа с заинтересованными лицами
Причина множества проблем проекта мы не слушаем или не слышим заказчика. Особенно это критично на самом старте, когда есть риск пропустить ответ на вопрос Зачем инициируется проект?
Кейс 1
Перед нами стояла простая задача заблокировать все возможные финансовые операции по договорам, которые не согласованы внутри предприятия. Мы посчитали эффекты и проработали, как нам казалось, все риски. Однако в ходе обсуждения главный пользователь утверждал, что это не сработает: У нас встанет производственный процесс. Это было похоже на отговорки, а основной заказчик подтвердил эту нашу гипотезу и настоял на том, чтобы просто делать.
В день икс по планам мы запустили функциональность, а где-то через полтора часа наш основной заказчик в не очень хорошем расположении духа позвонил и попросил откатить все назад: Это не работает!.
А как надо было? Прислушаться к опасениям пользователя, который знает специфику работы организации изнутри, и проработать эти риски. Всегда есть возможность найти варианты, которые устраивают всех.
Кейс 2
Это был функциональный заказчик, который прекрасно понимал задачу и систему, задуманную нами. Но мы не учли заинтересованность ИТ-департамента в реализации этого проекта и пришли к ним довольно поздно: на этапе проработки архитектуры. Пришлось пересматривать проект и сдвинуть сроки его сдачи. Мы потеряли время, деньги и репутацию, переоценив влияние и возможности функционального заказчика и недооценив внутренние отношения между подразделениями в крупной корпорации.
А как надо было? Подключить к работе над проектом всех заинтересованных лиц с самого начала и учитывать их интересы, не смотря на заверения заказчика.
Кейс 3
А это был кейс, который чуть не стал неудачным. Функциональный заказчик в лице генерального директора захотел изменить методологию учета себестоимости и по всем расчетам эффект от изменений должен был быть существенным. Команда из финансового блока была готова к изменениям и к моменту когда задача дошла до аналитиков из ИТ решение уже было принято. И вот здесь мы сработали как надо и спросили: Зачем? Как это будет работать? Кто будет поддерживать процесс? Как вы считали эффект?
Как итог эффект был пересчитан с учетом изменений в ERP системе и затрат на поддержание процесса и инструмента. Не только не стало эффекта в деньгах, но еще и были обнаружены дополнительные риски. Проект закрыли, а для сотрудников подразделения внутренней автоматизации задавать вопросы на старте стало правилом, даже если задача пришла от генерального директора.
Выводы:
- Всегда искать причину, цель, эффект. Аргументировать свою позицию. Как говорит один мой знакомый (классный менеджер): Выслушать, а не продавать Потом ещё раз выслушать и только потом продавать ;)
- Проживать один день с непосредственными пользователями продукта и детально узнавать их рутину. Это поможет предусмотреть все возможные нюансы.
- Прорабатывать все риски, которые кажутся вам, функциональному заказчику и любому заинтересованному лицу существенными. Особенное внимание уделить самым негативно настроенным к проекту заказчикам/пользователям. Они явно что-то знают! ;)
- Не упускать ни одного участника процесса. Участник процесса не может быть один, а уж ИТ-департамент нужно учитывать всегда!
2. Описание требований
Святая святых для любого аналитика описание требований. Рассмотрим ошибки в этой области на других двух кейсах.
Кейс 1
В одну из команд по разработке пришел проект, который требовал доработки. Система пришла с документацией, где описание логики работы системы было написано с использованием SQL запросов. К моменту начала работ, система уже была серьезно переработана и SQL-запросы потеряли актуальность. Пришлось потратить время на реверс-инжиниринг, чтобы понять логику и функциональность системы.
А как надо было? Перепроверить документы на актуальность и соответствие уровню развития проекта. Особенно при передаче его другим разработчикам.
Кейс 2
Это был интересный проект по автоматизации всех процессов внутри организации. В проекте было задействовано 5 систем различного класса, которые должны были интегрироваться друг с другом, чтобы процесс безостановочно продолжался. Команда проектировала архитектуру решения около двух месяцев, когда к проекту подключили меня.
В процессе общения с заказчиком я поняла, что он видит это одним образом, а разработчики другим. Это были минимальные на словах договоренности, которые полностью меняли проект. Пришлось начать всё с самого начала и проработать все требования с нуля: Зачем? Что? Как?
А как надо было? Четко описать не только требования к реализации процессов и подпроцессов (как это будет работать), но и то как будет выглядеть конечный результат.
Выводы:
Часто команды боятся замечаний заказчика и бегут разрабатывать, услышав ну вроде так. Можно считать, что вы нашли общий язык с Заказчиком, только если он сам начал вносить корректировки своими руками. Некоторым удобно читать тексты, другим схемы, третьим макеты интерфейсов. Попробовать стоит всё пока не нашли общий язык, пусть даже это будут рисунки на салфетках.
3. Проработка идеи, продукта или решения
Это истории про продуктовое управление, когда идея заполонила мысли, а все остальное неважно.
Кейс 1
У нас был классный продукт по автоматизации рутинных задач внутри организации: от внесения информации до ответа на любые вопросы сотрудников. И все было здорово: мы нашли первых клиентов, понимали рынок казалось там было очень много денег, запустили пару проектов и успешно их выполнили. И в этот момент открыли глаза: никто не просчитал стоимость поддержки решения. А оно в ноль стирало все возможные попытки заработать денег.
А как надо было? Тщательно просчитать все стороны проекта: от разработки до поддержки решения.
Кейс 2
Другая история когда мы не проработали рынок. Была найдена идея хорошего продукта, у которого не было конкурентов на рынке, но были заказчики. По крайней мере один, и он был готов платить и вкладываться. Мы влезли в этот проект и столкнулись с полным отсутствием теоретической базы для разработки такого функционала, но мы справились.
А после выхода с продуктом на рынок поняли, что не зря нет конкурентов. Очень многие пренебрегают этой функцией несмотря на все эффекты, которые она гарантирует.
А как надо было? Задуматься, почему в таком прибыльном секторе рынка нет конкурентов и докопаться до истины.
Выводы:
Проверять жизнеспособность проекта в рамках не одного заказчика, а конкурентоспособность согласно актуальной ситуации на рынке.
Культура неудач
Чтобы преодолевать трудности и снова не вляпываться в них, необходимо найти причину. Чаще всего она кроется в культуре неудач, которая принята в организациях. Есть два нехороших способа реагировать на неудачу в организациях:
-
Осуждение/наказание
Осуждая ошибки мы убиваем инициативу. Сотрудники боятся креативить и принимают только безопасные решения. Это приводит к стагнации в компании.
Решение: определить границы для ошибок. Нужно выделить ресурс на проявление инициатив и проверять их на контрольных точках. Ну а успешность проекта отслеживать по строгим критериям, оговоренным заранее. -
Замалчивание
Эта тактика приводит к повторению одних и тех же ошибок снова и снова. А это, в свою очередь, к потере позиций компании в глазах клиентов, конкурентов и рынка.
Решение: выстроить систему обмена опытом между сотрудниками. Обсуждение возможных вариантов решения неудач в итоге приводит к методологии, которая помогает избегать эти ошибки.
Разумная рефлексия помогает развиваться, но это не повод окружить себя исключительно неудачами. Ищите баланс, ведь учиться на успешных проектах куда приятнее
