Аналитик: цена ошибки VS цена ресурса

001 Диоген
Давайте взглянем на картину Якобса Йордана – Диоген, ищущий человека. И представим себе что в центре у нас аналитик: он достаточно опытен но еще многого не знает (солнце еще ходит вокруг земли, хотя модель требований уже ясна), его утомила бедность жизни (жить на зарплату меньшую чем у 70% его коллег), его грузят одновременно несколькими задачами по разным проектам, бизнес к нему относится как к продвинутой секретарше. Но он то знает что на нем ответственность проложить путь для проекта, он знает что он поводырь всего проекта и на нем чуть ли не вселенская ответственность за успех бытия проекта. Но остальные это не хотят видеть и понимать. А теперь без лирики – факты, графики и выводы. Побежали!
Все мы где-то читали в книгах по менеджменту, управлению проектами или анализу что самые дорогие ошибки делаются в самом начале проекта. Т.е. на этапах проработки концепции продукта проекта, анализа требований, архитектуры решения. Дальше идет большой кусок работы по выполнению проекта – разработка, внедрения. Но самые дорогие ошибки – в самом начале.

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

Что нам говорит практика?

  1. В самом начале пути у вас самые большие возможности исправить курс.
  2. Стоимость коррекций в самом начале незначительна
  3. Ошибка, допущенная на текущем этапе относительно не дорогая в исправлении
  4. Стоимость исправления ошибок сделанных на ранних этапах растет экспоненциально удалению этапов друг от друга
  5. Наибольшая стоимость проектных ресурсов как правило находится на последних этапах – большое количество реализаторов и внедренцев

Приведу для примера пару графиков. Первый график – пересечение кривых стоимости проекта и возможности влияния на результат проекта:

001 Influence VS Cost

График взят из статьи Four Keys to Finishing On Time and Under Budget

… и график стоимости исправления ошибок разных функций на разных этапах проекта:

001 Cost to correct

График на основе материалов книги Software Project Survival Guide.

Теперь выводы исходя из темы – цена ошибки, стоимость ошибки и влияние аналитиков:

  1. У аналитиков самое больше влияние на возможность что-то изменить в проекте на этапе анализа.
  2. Цена ошибки аналитика суммарно больше чем стоимость ошибки сделанной на других этапах

Что мы должны ожидать в связи с этим:

  1. Высокого уровня функциональных компетенций аналитиков – крутой аналитик
  2. Отличного понимания аналитиками прикладной задачи, которая им поступила на вход – аналитик в теме
  3. Согласованности действий аналитика и заказчика со стороны бизнеса – налаженное взаимодействие
  4. Верификация качества работы аналитика в различных аспектах – реализуемость, тестируемость, полнота, непротиворечивость – QA
  5. Достаточность выделенных их ресурсов для формирования достаточного уровня качества результатов на своем этапе – время есть, не разрывают на части и не дергают
  6. Качественное обеспечение их работы, поддержка бизнесом, помощь архитекторов и тп.
  7. Мотивация адекватная размеру и уровню риска проекта, ценности ожидаемого результата

Какие грехи допускает менеджмент проектов и бизнес при отношении к аналитику

  1. Нагружает (перегружают и разрывают) по принципу параллельного выполнения нескольких задач. В свою очередь аналитику нужно фокусировать на минимуме разных задач. Идеал – 1
  2. Платят минимум денег. Аналитики воспринимаются как “умный технический писатель”. В сравнение с “Богами компьютера” – программистами – их не воспринимают как что-то редкое и мистическое. С точки зрения бизнеса аналитик что-то пишет на бумажке (я бы тоже так написал если бы у меня было мало работы – думает бизнес), а программист – он маг и волшебник, никто не понимает как работают программы, компьютер и как летают самолеты. Все остальное ясно.
  3. Считают что аналитиком может быть любой – и часто аналитиком на первых этапах выбирается проактивная жертва из бизнес подразделения – без опыта в анализе, без понимания системы. Все риски связанные с анализом множатся и уходят в космос благодаря этому решению.
  4. Прессуют по времени. На поговорить нужно час, ну два. Записать – ну еще пол дня накинем. Как две недели? Как месяц? Вы что! Да мы сами напишем это в перерывах на обед за неделю .

Сегодня все эти проблемы подтверждаются на многих проектах, отражаются на рынке труда. Зарплаты аналитиков стоят не сильно много – изредка они подтягиваются к средней планке программистов. При том что 2 аналитика работает на проекте 1,5 месяца а потом команда разработчиков из 4-6 человек трудится над проектом 3 месяца – все равно считается что на анализе можно сэкономить и лучше добавить больше дорогих разработчиков. А графики роста стоимости ошибки все равно работают. И менеджмент уверенно добрасывает ресурс не на устранение проблем в будущем в виде качественных аналитиков и качественно выполненной работы аналитиками а в производство – на создание проблем и тушение пожаров. Смешно то что такие проблемы присущи до сих пор софтверным компаниям.

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

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

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

Вывод: Не оценивайтедлительность задач по времени! Оценивайте размер этой задачи, по отношению к другим задачам.

Ренди Мотте – 6 месяцев

Ренди Мотте – CIO HP, а до этого внедрял отличные ИТ решения в Dell и Wall Mart – на своем опыте пришел к вывод что если проект переваливает по длительности 6 месяцев – риски неулачи такого проекта резко повышаются.

Со своей практики могу также подтвердить данное эмпирическое правило. И чем сроки короче – тем как правило меньше рисков завалить проект.

Вывод: Любите малые и короткие проекты. Делите большие проекты на малые части. Чем быстрее тем лучше.

Архитектура определяет команду, команда – архитектуру

Замечательная вставка в книге Гибкое управление IT проектам от Джонатана Расмуссона с темой “Архитектуру нужно подбирать одновременно с командой” акцентирует внимание на казалось бы простом и очевидном факте –  то что люди делают  хорошо – то они и делают.

Если вы нанимаете команду Java разработчиков или команду SharePoint С# разработчиков для построения своего решения – то трудно себе представить что первые сделают решение на SharePoint а вторые – на Android. Теоретически заставить их можно поступить так – но очевидны конфликты на идеологической почве, огромные потери времени на обучение и очень высокая вероятность провала такого проекта.

На что в этом моменте стоит обратить внимание при выборе новой команды? Это опыт и то что говорят члены команды о себе – что они умеют делать хорошо. Опыт команды должен соответствовать тому что вы строите. Если вы строите корпоративный портал большой компании и планируете использовать все преимущества технологий Microsoft то вам не стоит нанимать для этого команду недорогих разработчиков на PHP или дорогих консультантов по построению IBM решений.

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

Козлы и капуста

Постоянно наблюдаю на практике как заказчики провоцируют завал проекта в самом начале. Что они любят делать?

  • Не знают зачем это хотят
  • Не знают что конкретно хотят
  • Выбирают поставщика по цене.
  • Заранее вводят несколько ограничений в проект делая баланс не реальным. Например фиксируют сроки и давят по цене задавая требования в качестве.
  • Не оценивают команду поставщика. Не проверяют компетенции поставщика – его команды.
  • Не проверяют офис поставщика. А есть ли офис ВООБЩЕ? А какой он? А много ли там программистов? А не выглядят ли программисты как юродивые или пацаны со второго курса морборпуфпахфак?
  • Редко делают референс визиты к клиентам поставщика.
  • Выбирают там где могу получить легче взятку.
  • Провоцируют поставщиков снижать цены. Тем самым формируют основания для создания условий по понижению объема работ через хитрости в описании ТЗ, выделение на проект более дешевых ресурсов, снижение буферов на риски и вариации – все это создает самые отвратительные условия для взаимной работы. Когда мало денег обоим сторонам очень не комфортно.
  • Не устраивают очных ставок между поставщиками. Собранные поставщики вместе могут отлично друг друга дополнить и вы докопаетесь до истины.
  • Требуют дать детальный план проекта длительностью в 6-8 месяцев при описании требований к нему на 1-2 листиках
  • Не согласны на гибкую разработку. Составьте план по дня, приложите к договору и мы все 6 месяцев будем с ним сверяться. За каждый шаг влево-вправо – расстрел.
  • Отказываются формировать четкое ТЗ. Один из встречаемых аргументов – так это мы потом получим то что будет написано
  • Отказываются заказывать отдельно разработку ТЗ чтобы по нему потому получить правильную оценку. Аргумент – а вот мы заплатим одним – а другие потом не захотят делать это ТЗ (Бред! Хорошее ТЗ всем в радость кроме нерадивых заказчиков и исполнителей). Аргумент – а вот мы проанализируем и окажется что у нас не будет столько денег чтобы выполнить проект (Бред! Размер проекта можно увидеть при беглом анализе – а при точном правильно сформировать ожидания)
  • Предлагают не писать ТЗ – тут и так все понятно. Этот процесс вы уже раз пять делали – нам такой же как в той компании.
  • А зачем мы тратим столько времени и денег на тестирование и на анализ? Что тут и так не понятно что надо делать правильно и качественно?

Уникальные проекты слабо регламентированы и их успех полностью зависит от …

“Уникальные проекты слабо регламентированы и их успех полностью зависит от личности менеджера проекта и климата в команде проекта, то есть от того самого человеческого фактора, от которого вы наверняка хотели бы отказаться. Однако если суть бизнеса заключается в реализации именно таких проектов, то нужно с этим просто смириться”

книга “Управление проектами”
- познакомиться - http://mann-ivanov-ferber.ru/books/paperbook/upravlenie_project/
- прочитать - http://www.ozon.ru/context/detail/id/7604020/?partner=mif

Распределение полномочий в проекте

Очень поучительная презентация о правильном распределении и балансе полномочий в проекте от Дмитрия Безуглого. Презентация актуальна для руководителей проектов, менеджеров, аналитиков и архитекторов.

Запустите нам MS Project – мы будем теперь управлять проектами

Бывает такое – приходят к тебе из бизнес подразделения – и говорят – у вас есть Microsoft Project Server, мы уже даже поставили себе на компьютеры Microsoft Project. Мы хотим теперь управлять проектами. Причем сделайте нам под ключ и скажите куда и как нажимать. Стоп, стоп, стоп! Нужно подумать и задать вопросы заказчику.

Подробнее читать тут.