Дальше я расскажу об основных ошибках при оценке, которые встречаются. Я выделил 10 самых главных ошибок. Первые три связаны с требованиями.

Итак, первая ошибка заключается в том, что, как я уже говорил, правильно оценить проект без понимания требований в принципе невозможно.

• Нужно постараться приложить как можно больше усилий для того, чтобы перед ответом на вопрос «Сколько это будет стоить?» сначала  понять, что же конкретно мы должны сделать. Очень большая ошибка — вписываться в проект, требования к которому слишком общие, потому что правильно оценить его практически нереально (либо нужно заведомо закладывать большие риски).
• При этом нужно обязательно учитывать, знаем ли мы те технологии, которые предполагается использовать в проекте. Допустим, если результат должен опираться на какие-то новые технологии, которые мы ни разу не использовали, но нам кажется, что они работают – это вовсе не означает, что все будет так просто, как мы хотим.

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

Вторая ошибка – это полагаться при оценке только на сформулированные заказчиком требования.

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

И когда мы потом начинаем делать проект, то оказывается, что все совсем не так, либо то, что нам изначально дали – это какая-то малая доля, которая никогда не будет достигнута, пока мы не сделаем еще в 10 раз больше других необходимых работ.

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

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

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

Также часто встречается ситуация, когда оценка делается только силами менеджеров по продажам. Например, на одной из конференций (на партнерском семинаре 1С) выступал коммерческий директор одной из крупных фирм-франчайзи 1С, который говорил, что ему не нужны руководители проекта для оценки, он сам лучше них может все оценить и продать.

Да, он продать может, причем хороший менеджер по продажам продаст не только заказчику, но еще и убедит свое руководство и проектную команду в том, что он все правильно оценил. Однако совсем не факт, что это действительно будет так – все выяснится во время реализации.

И обратная ситуация – когда оценка ведется только силами технических специалистов.

Дело в том, что, как правило, программисты склонны переоценивать свои возможности, и это, скорее всего, будет недооценка. А руководитель отдела разработки, наоборот, склонен закладывать в оценку слишком большие риски, перестраховываться – может получиться переоценка.

Поэтому здесь правильнее создавать симбиоз менеджера по продажам с техническими специалистами. Кстати, есть такая статистика — чистое время программиста, которое ему требуется для реализации задачи можно помножить на 3-3,5 раза.

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

Следующая ошибка – это отсутствие процесса оценки как такового. Чтобы правильно оценить проект, процесс оценки в компании должен быть хоть как-то построен.

Он может быть простым или сложным, но это должен быть выделенный процесс оценки – должны быть расписаны конкретные шаги процесса, его начало и окончание.

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

Еще одна ошибка – применение излишне формальных подходов к оценке. Допустим, мы выработали некий метод оценки, и постоянно ему слепо следуем – этого нужно стараться избегать.

• Нужно учитывать ошибки и находить для себя наиболее  подходящий вариант.
• Лучше применять те методы, которые давали хороший результат.
• Излишнюю бюрократию тоже устраивать не нужно. 
• 
  Еще важный момент: бывает, что в проект изначально закладывают новую технологию – допустим, вышло какое-то новое решение от 1С, или вышла  новая платформа, появились новые возможности. К подобным экспериментам всегда нужно относиться с осторожностью:
• Нет никакой гарантии, что если новые возможности задекларированы, они в этом проекте заработают.
• Вполне возможно, что это будет не так, и, соответственно, могут возникнуть очень большие проблемы

Также весьма большую трудоемкость в проекте могут занимать сами процессы согласования результатов работ и различного рода документации. Часто этот момент просто игнорируют: оценили стоимость разработки, стоимость внедрения – и все.

• Причем, чем больше заказчик, тем таких моментов больше.
• Особенно, если это госструктура – там до 50% времени может занять только процесс управления бумажками и прочей бюрократией. И к этому нужно тоже относиться внимательно.

Ну и последняя ошибка – это при расчете сроков проекта заложить, что вся команда будет работать полный рабочий день, по 8 часов в день.

• Команда не будет так никогда работать, потому что, во-первых, все люди – они могут потеряться, уволиться и т.д.
• Есть вынужденные перерывы, например, когда заказчику может потребоваться время на осознание и согласование каких-то промежуточных этапов. Все это будет растягивать процесс.
• Даже если программисты будут работать в штатном режиме, вряд ли они будут программировать все 8 часов. Поэтому не рекомендуется закладывать на выполнение какой-то конкретной работы более 60% рабочего времени.
• Нельзя просто так – если вы, допустим, посчитали трудоемкость 100 часов, перевести это в рабочие дни и сказать, что проект будет выполняться столько. Ну не будет он столько выполняться.

Как говорится, в проектном управлении есть такая маленькая шутка – следствие закона Мерфи: «Если в проекте что-то может пойти не так, оно обязательно пойдет не так».

По итогам проектов нужно стараться накапливать базу потенциальных рисков, которые вообще могут возникнуть. На начальном этапе можно сесть и вспомнить все проблемы, которые возникали в последних проектах (неважно, по каким причинам), и выписать весь этот перечень.

Пример проблемы: необходимость наличия удаленного доступа. Заказчик пообещал, что у вас будет удаленный доступ, чтобы было проще работать. Вы подписали контракт, но этого нигде не указали.

А когда к нему пришли, он сказал: «оказывается, у нас служба безопасности это запрещает, и у вас не будет удаленного доступа».

Соответственно, вам теперь приходится каждый раз ездить к нему, и ваши затраты сразу резко возрастают.

• Следовательно, у вас должен быть где-то зафиксирован перечень тех проблем, которые могут возникнуть.
• А когда вы беретесь за  новый проект, вы просматриваете весь этот перечень возможных рисков, накладывая его в уме на текущую ситуацию, ианализируете, что из этого может быть актуально конкретно в данном проекте. Получается уже некий более узкий перечень из тех проблем, которые мы хотим решить непосредственно здесь.
• И, по сути, каждое такое опасение нужно проработать, постараться примерно оценить его для себя в деньгах. Если вы считаете, что в данном проекте конкретная проблема ничтожно мала, и если она и случится, то у вас ничего страшного не произойдет – ее можно игнорировать. Но если проблема действительно существенна, то, по крайней мере, ее надо как-то задокументировать. То есть, вы озвучиваете заказчику, что у вас есть такое опасение – и тогда возможны два варианта:
  • Первый вариант – это когда заказчик берет ответственность на себя и говорит: «если это случится, я проблему решу». Тогда вы фиксируете в договоре, что заказчик берет эту ситуацию на себя.
  • И второй вариант – когда он говорит: «нет, я этого не решу, но этого не случится».Тут уже вы можете заложить риск в бюджет как некий оцененный, как опасение, что такая проблема может произойти, и это уже может проходить у вас как определенное обоснование цены.

В заключение скажу о необходимости непрерывного совершенствования процедуры оценки.

• После каждого проекта обязательно нужно сравнить планируемую оценку с реальными затратами: посчитали по факту, какие работы выполнялись, какие трудозатраты на это пошли – сравнили их с планом.
• Это позволит сделать выводы для внесения уточнений в саму процедуру оценки, чтобы ее непрерывно совершенствовать. Потому что если оценка окажется хаотична  – значит, никакого процесса оценки как такового не было.

Также очень важно, чтобы при проведении такого анализа учитывалась эффективность управления проектом.

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

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

Оригинал: http://1c.bishelp.ru/public/340027/

Некоторые важные выводы по итогу исследования ИТ-проектов

Вы никогда не задумывались о том, какова вероятность получить серьезную выгоду от внедрения ИТ-системы? Компания The Standish Group в 2014 году выпустила отчет, в котором был получен ответ на этот вопрос. При чем, для ответа на вопрос были взяты успешные ИТ-проекты, завершенные в плановый срок, плановый бюджет и достигшие при этом установленных перед проектом целей.

Итак, среди успешных проектов была получена следующая картина относительно выгод, полученных от проектов:

Как видно из диаграммы, 73% из успешных ИТ-проектов позволили получить высокую или среднюю выгоду для компании, заплатившей за результаты ИТ-проекта. Вместе с тем, в 15% проектов, признанных успешными, выгоды были слишком ничтожны для Заказчика проекта. А, значит, команде проекта трудно гордиться своей работой.

Нет ничего более глупого, чем платить за то, то Вы никогда не будете использовать. Второй вопрос, на который мы получили ответ благодаря данному исследованию был следующим – какая доля функциональности ИТ-системы, за которую заплатил Заказчик проекта, реально нужна для работы пользователям? Ответ на этот вопрос на следующей диаграмме!

• 
• Как видим, 20% от оплаченного функционала приобретенной ИТ-системы используются пользователями часто, еще 30% функций используются редко и 50% от приобретенного функционала ИТ-системы не используются практически никогда.
• На месте Заказчика проекта я бы задал вопрос: для чего Вы тратите деньги на 50% функций, которыми в лучшем случае воспользуются  несколько раз за всю историю эксплуатации ИТ-системы?

Если Вы заплатили за кастомизацию коробочного ИТ-продукта 100 тысяч долларов США (а проектов, к примеру, по внедрению ERP-систем с таким бюджетом в Беларуси большинство), и при этом 50% доработанного функционала никогда не будет использоваться, Вы выбросили на ветер 50 000 долларов.  А если Ваш проект кастомизации программного продукта стоил 1 млн долларов США (такие проекты внедрения ERP для резидентов Беларуси также известны), а результат по использованию функционала был тем же? Масштаб выброшенных денег в этом случае поражает!

Приведу еще один интересный факт – исследование показало, что менее 40% организаций имеют навыки оценки стоимости проекта. Управление тройным ограничением проекта – это скорее искусство, чем наука. Однако, любое искусство граничит с наукой, а навыки формируются в том числе после приобретения знаний.

1. Насколько хорошо развиты навыки оценивания проекта у тех руководителей проекта, которые попали в поле зрения исследования The Standish Group, показывает следующая диаграмма:
2. 
3. Отличными и хорошими навыки оценивания исследователи сочли только у 38% планировщиков проектов.
4. Итак, небольшие выводы из исследования:

• Прежде чем начинать ИТ-проект, попробуйте оценить выгоды, которые вы ожидаете получить от его реализации (как можно это сделать, я писал тут).
• В случае, если вы сейчас выполняете роль Заказчика ИТ-проекта, подумайте о том, как не «золотить» Вашу ИТ-систему функциями, которые никогда не будут использоваться. Думайте о том, как побыстрее нащупать и внедрить 20% функций, которые будут применяться пользователями ИТ-системы часто. А затем добавьте еще 30% функций, которые будут востребованы изредка.
• Нанимайте на управление ИТ-проектом профессионального руководителя проекта, который будет останавливать вас от непродуманных шагов по добавлению ненужных функций, а, главное, сможет вовремя спрогнозировать, каким станет срок и бюджет проекта, если Заказчик не остановится в своих неуемных желаниях по поводу функционала продукта, и сможет наладить управление изменениями в проекте.
• Если вы считаете себя профессиональным руководителем проекта, не переставайте развивать свой навык оценивания объемов работ. По-моему, навык оценки объемов работ – чуть ли не самый важный навык руководителя проекта, который надо развивать в себе на протяжении всей карьеры в управлении проектами (об этом я уже писал в статье ранее).

Основные проблемы в управлении ИТ-проектами, и как их избежать

За десять лет работы компании мы накопили солидный опыт в проектной работе и решили поделиться своими реальными историями. На каждом этапе реализации проекта встречаются свои сложности: подробно разбираем их в этом материале. В статье не будет теории и пространных размышлений, делимся только своим опытом на примере реализованных кейсов.

Разработка MVP

Заказчик часто не понимает, почему важно максимально быстро выпустить продукт. В Lodoss Team мы сразу предлагаем клиенту начать работу с запуска MVP.

MVP — minimum viable product — минимальная рабочая версия продукта, которую можно быстро создать и протестировать на пользователях. Это помогает собрать данные и понять готовы ли пользователи покупать продукт, насколько он им интересен.

MVP позволяет быстро запустить продажи и получить представление о коммерческой ценности разрабатываемого продукта. Это лучше, чем через год сделать идеальный с точки зрения разработчика, но никому не нужный на рынке продукт.

Заказчик с помощью MVP может:

• Как выбрать надежного платежного провайдера;
• Почему кастомизация эквайринга — это важно;
• Что предлагают лидеры рынка;
• Как подключить онлайн-платежи для сайта;
• Как достичь максимальной конверсии платежей.

Узнать

Реклама

• сэкономить деньги и время;
• протестировать свой продукт на живых пользователях;
• скорректировать стратегию и роадмап;
• собрать пул лояльных пользователей.

Очевидно, что это нужно — но как понять, какие части продукта включить в MVP? Для этого надо чётко собрать исходные требования, понять, какая функциональность критически важна, а какая вторична и может быть реализована не на старте, а в дальнейшем.

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

Однажды в компанию обратился заказчик с не совсем обычным проектом — он хотел создать новую социальную сеть. Деньги на разработку и запуск проекта у него были. Человек был увлечён проектом и каждую недели генерировал множество идей.

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

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

Через полгода он нашёл финансирование и захотел доработать проект. Ещё несколько месяцев мы дорабатывали мобильное приложение: реализовывали новые фичи, придуманные заказчиком. Аналитику своих гипотез он не проводил, MVP не тестировал, что привело к печальным результатам.

Деньги на проект опять кончились, проект закрылся, а мы даже не смогли положить его себе в портфолио.

Если бы заказчик внял бы нашим советам создал бы MVP, провёл аналитику и проверил гипотезы, то, скорее всего, его соцсеть сейчас жила бы и нашла своих пользователей.

Сбор исходных требований

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

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

Он обратился к вам как к профессионалам и не должен изучать ИТ-лексикон, чтобы понимать, о чём вы ему рассказываете.

На этом этапе часто возникает проблема — убедить клиента, что ему необходимо зафиксировать свои требования и пожелания к проекту в ТЗ. Как правило, многие не понимают, зачем это нужно, или просто не могут составить грамотное техзадание. Вместо ТЗ приносят просто список неоформленных желаний, без структуры, ви́дения и целей, которых необходимо достигнуть. Для чего нужно техзадание?

Когда работа идёт по гибким методологиям (почему для работы мы выбрали их, читайте дальше), ТЗ — это не жёсткий монолит, от которого нельзя отступить ни на шаг. Этот документ помогает расставить приоритеты и определить главные задачи, выделить функциональность MVP и разделить её на майлстоуны.

Предпроектная аналитика

Подобных проблем позволяет избежать предпроектная аналитика. С её помощью можно выявить скрытые сложности и подводные камни проекта, о которых может не подозревать сам клиент. Часто заказчик не видит необходимости проводить аналитику, он считает, что досконально знает проект и может чётко описать необходимый объём работы. Наш опыт показывает, что в 90% случаев это не так.

Совсем недавно мы делали проект сайта для сети аквапарков. Заказчик не мог сформулировать чёткие требования и хотя бы примерно оценить объём работ. От нашего предложения провести предпроектную аналитику отказывался.

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

Из-за этого финальная оценка всего проекта оказалась в два раза больше первоначальной.

Мы точно оцениваем только небольшие проекты до 1000 часов. Если проект большой, разбиваем его на майлстоуны, а их в свою очередь дробим на двухнедельные спринты. Уточняем исходные данные: погружаемся в бизнес заказчика, проводим предпроектную аналитику и на основе её данных помогаем составлять подробное ТЗ.

Однажды мы взялись за реализацию проекта Souqina. Это iOS-приложение типа Instagram, с помощью которого можно напрямую покупать вещи у блогеров, брендов и сообществ. Мы дали заказчику первичную оценку стоимости и сроков работ по проекту. Сделали это для ознакомления — чтобы он понимал порядок цен. Сразу после старта мы погрузились в проект, проводили исследования и уточняли требования. Соответственно, корректировали и бюджет, что встречало жёсткое непонимание клиента. В его голове уже жёстко зафиксировалась озвученная нами цифра. Дальнейшая работа с заказчиком свелась к спорам о каждой новой копейке, появившейся в смете. Проект мы в итоге сдали, но потратили огромное количество нервов и лишнего времени на переговоры. После этого случая решили, что это — не наш вариант.

Проект Souqina

Мы не даём оценок всему проекту целиком, если на его реализацию требуется больше тысячи часов. Сначала чётко прорабатываем все требования, на основе которых разбиваем проект на майлстоуны. Так как каждый майлстоун значительно меньше 1000 часов на одного разработчика, значит мы можем дать на него конкретную оценку и нести ответственность за сроки.

Выбор методологии

Управление ИТ-проектами отличается такими особенностями, как сложность, быстрая изменяемость и высокие риски. Это накладывает определённые требования к подходам, применяемым при их реализации.

Существует два основных: проектный (модель водопада) и процессный (гибкая методология). Возможны различные сочетания этих подходов в зависимости от целей, задач и содержания проекта.

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

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

В Lodoss мы используем гибкую методологию и работаем по scrum-модели: реализуем проект спринтами по две недели. Каждый спринт заканчивается измеримым результатом: выпуск MVP, релиз или исправление пула багов.

Такой подход даёт клиенту возможность:

• вносить дополнительные требования по ходу проекта;
• решать непредвиденные проблемы «на лету»;
• реализовывать идеи, возникающие в процессе работы;
• корректировать реализацию;
• экономить ресурсы. Для тестирования гипотезы не нужно делать весь проект и тратить на него полностью бюджет — достаточно создать MVP.

Поэтому мы поступаем следующим образом: оговариваем с клиентом ориентиры, чтобы он представлял порядок цен. После этого разбиваем проект на майлстоуны по одному–полтора месяца. Это позволяет максимум через полгода выпустить MVP — как правило, для этого достаточно одного–двух месяцев. 

Такой подход работает, когда объясняешь клиенту, что несмотря на то, что он всё продумал заранее, он всё равно захочет вносить изменения в процессе работы. Это наш выстраданный опыт — не было ни одного клиента, который бы не хотел что-нибудь изменить при реализации проекта. Поэтому нам нужна гибкость в разработке, чтобы мы могли вносить правки в новый майлстоун.

Выбор эффективных инструментов

Берясь за конкретный проект, важно уже на старте понимать, какими инструментами вы будете пользоваться. Кому-то удобно работать в связке с CRM, а кому-то — строить диаграммы Ганта.

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

Будут ли используемые в компании инструменты эффективны на проекте большого масштаба или новой для вас специфики.

Когда мы разрабатывали проект TroveSkin для Android-платформы, мы решили, что нам хватит функциональности обычного email. В переписке по электронной почте мы обсуждали детали новых фич, оценку сроков, их утверждение и многое другое. В итоге структура писем стала слишком сложной и размытой, тяжело было найти информацию по задачам из предыдущих спринтов.

Проект TroveSkin

Тогда мы решили ввести инструмент для общения с клиентом по новым фичам, который поможет решить эти проблемы.

Мы выбрали Trello: в первый столбец клиентом или менеджером вводились хотелки, затем они проходили ряд преобразований: оформлялись в задачи, задачи помечались тегами — какую платформу они затрагивают, по каждой задаче шло прикреплённое к ней обсуждение. В итоге к каждой задаче прикреплялась оценка и выставлялся приоритет.

Из таких готовых тасков менеджер совместно с клиентом составляли очередной спринт и потом его утверждали. Такой спринт уходил в приложение к договору, а также помещался в Jira, где с ним работала техническая команда.

Плохой менеджмент и ошибки при проработке требований заказчика

Бывает, клиент просит что-то изменить, докрутить или добавить новые фичи уже в ходе работы над проектом. Иногда проджект-менеджеры идут у заказчика на поводу и автоматически добавляют все его требования. Проект обрастает новыми ненужными фичами, как пираты Карибского моря ракушками. Команда работает на пределе возможностей, а нужного результата нет.

В 2017 году мы начали работу над проектом Sellsay. Изначально проект казался небольшим: необходимо было лишь дополнить офлайн iOS-приложение функциональностью для многопользовательского режима. Здесь мы объяснили клиенту, что помимо мобильного разработчика, для реализации серверного функционала и панели администратора ему понадобятся бэкенд- и фронтенд-разработчики.

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

С менеджером проекта мы поговорили, но ситуация не улучшилась, так что пришлось его поменять.

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

Синхронизация и тестирование

Когда на проекте задействованы специалисты разных платформ, то всегда есть риск рассинхронизации: исполнители по-разному понимают задачу или реализуют какой-то функционал совершенно разными средствами.

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

Она занимает 5–10 минут и представляет собой обсуждение текущей работы и проблем.

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

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

Учёт изменений на проекте и документация особенностей

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

Обязательно нужно вести документацию хотя бы на уровне бизнес-логики — как бы ни казалось, что всё понятно и в головах менеджера/разработчика/тестировщика всё есть, вам не хватит ни воспоминаний, ни переписки, ни комментариев в Jira, чтобы выяснить «почему мы сделали именно так полгода назад». Это достаточно ресурсозатратно, но поверьте, стоит того.

Именно такую ошибку мы допустили, когда работали над проектом Fearless Little — социальной сетью по интересам. После того как проект был в разработке два года, его передали новому бекендеру. Ему было крайне тяжело разобраться в проекте, приходилось постоянно отвлекать других членов команды и задавать кучу вопросов. По-другому нельзя было понять, почему использовались конкретные решения, или сделать оптимальный выбор новых. Это было болезненно, трудозатратно, а главное — потребовало огромного количества времени. Если бы в ходе проекта велась хотя бы какая-то документация, таких бы проблем не было.

Главные рекомендации

Мы составили чеклист рекомендаций, которых необходимо придерживаться при работе над ИТ-проектами:

• везде, где позволяют масштабы проекта, создавать MVP;
• проводить предпроектную аналитику;
• фиксировать первичные требования в ТЗ;
• не давать клиенту ложного представления о том, что первичная оценка — это обязательства выполнить весь проект в этот срок;
• выделять майлстоуны и работать по спринтам;
• выбрать подходящие инструменты для менеджмента;
• грамотно управлять требованиями заказчика;
• синхронизировать работу команды;
• вести документацию по ходу проекта.

Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.

13 правил внедрения IT-систем | Карьера и свой бизнес

С другой стороны, слишком много проектов, которые либо не состоялись вовсе, либо не принесли компаниям желанного эффекта. И не имеет значения, шла ли речь о внедрении CRM (Customers Relationship Management) или организации колл-центра, видеоконференцсвязи или системы управления проектом. Ошибки одни и те же. Что нужно знать владельцу бизнеса, чтобы их избежать?

— Сотрудник службы IT в компании ближе к рынку интеграторов, чем к той отрасли, в которой работает компания, — в силу образования, профессиональных и не только профессиональных интересов. В бизнесе своей компании он обычно разбирается хуже, чем в IT. Это приводит к тому, что он больше работает на наш рынок, чем на бизнес своих акционеров.

— Рынок сильно подвержен моде. Вендоры вкладываются в продвижение своего нового решения, кто-то устанавливает его, и начинается волна: «У Васи есть, мне тоже надо». Пятый год, например, модно внедрять CRM. Перед кризисом началась мода на колл-центры.

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

Надо считать, что выгоднее.

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

Те проекты, где инициатором выступает не «айтишник» компании, а директор по продажам или по развитию — люди, которые четко знают, какую задачу они хотят решить, — идут быстрее и гораздо эффективнее. Инициатором проекта должен быть тот, кто будет пользоваться этим проектом.

Иначе идея умирает на уровне обсуждения коммерческого предложения.

— Технология не панацея. Та же CRM — лишь одна из систем для автоматизации определенным образом организованных процессов. Пример такой системы — советская библиотека, где по буквам распределены карточки на всех читателей. Известно, кто что брал, когда в последний раз обращался, есть ли задолженность.

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

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

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

— Мы всегда спрашиваем, как компания видит свой бизнес через три года. Нет смысла внедрять дорогостоящую систему, если она решает только сиюминутные задачи. В нашей стране трудно что-либо планировать.

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

А оказалось, что они посчитали только нагрузку операторов, на самом деле количество обращений — 30 000 в день, просто раньше люди не дозванивались. И в течение месяца после старта проекта на новом оборудовании мощности не хватило.

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

— Не бывает одинаковых проектов. Даже если мы берем два банка одного размера, бизнес-процессы в них будут выстроены по-разному, потому что владельцы разные. Чтобы посчитать, выгодно ли то или иное решение для его бизнеса, какого результата можно достичь, клиент должен дать нам информацию именно о своем бизнесе.

Например, если речь идет о видеоконференцсвязи, надо посчитать, сколько он сможет сэкономить на командировочных, проезде, гостиницах, сколько стоит время топ-менеджеров, потраченное на разъезды и на ожидание в аэропортах. В одном банке решение о том, что надо внедрять проект по корпоративной телефонии, приняли мгновенно, как только посчитали, какая может быть экономия.

Банк имеет разветвленную и географически распределенную филиальную сеть, АТС филиалов были соединены через общую телефонную сеть. Только за счет того, что АТС объединили в одну систему, использовав широкополосные каналы передачи данных, расходы сократились на 25%.

Если же клиент никогда не озадачивался сбором таких данных, мы не можем подготовить ТЭО, где можно было бы показать планируемый эффект от внедрения.

— Надо понимать, что внедрение — проект двух компаний. По-другому не будет никогда. Встречаются представители заказчика, которые в какой-то момент перестают давать информацию, затягивают сроки, говорят, что им «не дали распоряжения».

Это не наша кухня, это проблемы внутри компании: люди не мотивированы на то, чтобы сделать этот проект, чтобы бизнес стал лучше. Ни один проект не реализуется на 100% по плану. Но если обе стороны контролируют процесс и открыты, все ошибки можно исправить.

— В идеале со стороны клиента руководить проектом должен человек, у которого достаточно полномочий и есть живой, очень личный стимул сделать этот проект хорошо.

Иначе проект не будет реализован никогда или будет реализован плохо. И в этом будет виноват системный интегратор, как водится. У нас был рекорд по обсуждению проекта — три года.

Видимо, внутри компании просто не понимают, зачем им это надо.

— Все технические меры должны быть подкреплены административными. Как сделать так, чтобы продавцы пользовались системой CRM? Где-то в глубине души они понимают, что нужно. Но это лишняя работа — все переговоры, все отчеты заколачивать в компьютер. Да и страшно. Основной капитал продавца — его клиенты, чем меньше о них знают окружающие, тем ему комфортнее.

А тут нужно все раскрыть. Руководитель может в любой момент посмотреть, чем сотрудник занимается. Внутренний саботаж нововведениям всегда будет. Единственный способ его избежать — сделать так, чтобы невозможно было работать без этой системы. Например, чтобы электронная почта ходила только через CRM.

Или установить создание карточки контакта в CRM при каждом телефонном звонке.

— Есть стоимость приобретения системы и стоимость внедрения. И рассчитывая расходы, надо учитывать стоимость сопровождения системы. Часто бизнес не хочет дорого платить за проект, он не понимает, что, заплатив единовременно 3 копейки, будет выкладывать по 30 копеек все последующие месяцы за поддержание системы. И проект обойдется в итоге гораздо дороже.

— Не бывает систем, которые работают автономно. Значит, данные в нее заколачиваются ручками и переносятся из нее в другие системы тоже ручками — это и трудозатраты, и ошибки. Любая система должна быть интегрирована со всеми смежными системами.

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

— Сервис стоит денег. У меня был случай, когда у клиента что-то сломалось, специалист починил все за 15 минут, а клиент спрашивает: «За что я деньги отдал?» Сразу вспомнила анекдот про «шашечки или ехать».

Объяснила, что, если ему надо, чтобы это быстро заработало, услуги профессионала столько и стоят.

Если бы я нагнала 10 человек, которые возились бы неделю, было бы понятнее, за что уплачено? Стоит посчитать, что дешевле — поддержка системы или ее простой.

Автор — генеральный директор компании «Оберон»

ROI не достаточно для обоснования ИТ-проектов

Посчитать каким будет ROI (или возврат на инвестиции) в ИТ-проекте довольно просто.

ROI = сумма прибылей / сумма инвестиций

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

Нередки случаи, когда ROI в проектах составляет 100%, 200% или даже 400%. Однако, в таких проектах необходимо обращать внимание на:

• Размер начальных инвестиций в проект;
• Время достижения точки безубыточности в проекте или срок окупаемости проекта;

Срок окупаемости = Инвестиции / (Денежный поток за период  + Амортизация)

• Период времени, используемый для расчета ROI.

• И еще один важный показатель – NPV (Net present value, чистая текущая стоимость) – измеряет чистую прибыль проекта в денежном выражении.
• Несколько кейсов:

ROI	Срок окупаемости	Чистая прибыль
Розничная торговля	415%	2 месяца	8.1 млн. $ за 3 года
Услуги перевозок	196%	3.9 млн. $ за 14 месяцев
Транспортная компания	424%	6 месяцев	3.7 млн. $ за 5 лет

«Большой ROI еще не означает, что вы действительно получите или сэкономите больше денег, а также то, что этот проект лучше, чем проект с маленьким ROI» – отмечает Глен Клуни (Glenn Clowney), президент компании ROI-Calc Inc., разрабатывающей веб-приложения для вычисления ROI.

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

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

Финансовые метрики ничего не значат, если вы не собираетесь подводить итоги

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

«Если вы не спросите «Почему» по крайней мере пять раз, вы не докопайтесь до причин по которым были сделаны те или иные инвестиции», — комментирует Клуни.

Часто в бизнес кейсах недооценивают такой параметр, как совокупная стоимость владения (TCO), потому что не смотрят на то, что лежит за пределами собственно стоимости. Простой пример – принтер, который стоит 70$. Однако с учетом стоимости тонера, бумаги, доставки принтера и расходных материалов и т.д. – он обойдется более чем в 600$ за три года.

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

Например, при оценке внедрения ERP-системы обычно учитывают стоимость ПО, сотрудников занятых в проекте, затраты на работу партнеров и вендоров, расходы на программу обучения.

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

По данным Forrester Research от 30 до 70% ИТ-проектов не достигает установленных при планировании показателей. ИТ службы часто переоценивают свои возможности в реализации проектов и не учитывают историю своих предыдущих «успехов». Неудивительно, что завышенные предположения о ROI могут быть неоправданными.

Собственно не так важно, какие именно показатели вы используете для обоснования проекта  – ROI или NPV – гораздо важнее проанализировать тот результат, который вы получите после завершения проекта.

По материалам статьи Линды Тукки (Linda Tucci) на сайте SearchCIO.com