Особенности проведения оценки трудозатрат аналитиком

Как-то, в ходе обсуждения с коллегами проблем несоблюдения сроков по проектам было упомянуто название книги «Критическая цепь» Э. Голдратта. Книга показалась нам интересной, легко читается (хотя, конечно, не без «воды») за счет того, что автор в художественном стиле предлагает свой подход к эффективному ведению проектов. Мы не будем пересказывать основные постулаты книги, а остановимся на обсуждении лишь одного из них – оценивая проект, мы страхуемся и существенно завышаем трудозатраты, однако это не помогает завершить проект в срок.

Кратко перечислим факторы, на которых основывается подобное утверждение:

1. Оценивая каждый элемент работ (например, анализ-согласование-разработка и т.д.) исполнитель:

a.   Отталкивается от имеющегося негативного опыта.

b.   Называет сроки, которые нам гарантируют, что мы уложимся в них с вероятностью не менее 80% (или выше) даже если сработают все риски.

с. Накидывает дополнительную страховку от “урезания трудозатрат сверху”.

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

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

1. Синдром студента - зная, что “времени еще много” исполнитель приступает к работе в последний момент.

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

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

a. Это может создать прецедент для будущего давления и снижения трудозатрат менеджерами.

b. Освободившееся время можно использовать в личных целях.

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

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

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

Однако, в условиях высокой конкуренции на рынке разработки ПО, все чаще наблюдается обратная ситуация: клиент диктует стоимость и сроки, и трудоемкость спускается “сверху”. И чаще всего эти сроки и трудоемкости изначально далеки от реального объема работ. При этом, каждый вышестоящий уровень менеджеров пытается еще и дополнительно подстраховаться, но уже в другом направлении и называет нижестоящему уровню цифры минимум на 10% меньше тех, что обозначил клиент. Как результат, сотрудникам, на которых оказывают давление руководители и менеджеры, приходится работать сверхурочно и без выходных, им брошен серьезный вызов (для некоторых, правда, это даже может стать дополнительным источником мотивации). Но возможно ли долго работать долго в таком темпе? Ответ — нет, нельзя. Работая на износ, люди теряют мотивацию, быстро выдыхаются, а их эффективность и вовлеченность в проект падают. Подробнее о подобной ситуации можно прочитать, например, в книге “Путь камикадзе” Э. Йордона.

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

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

Теперь предлагаем спуститься на прикладной уровень. Что же в таких ситуациях делать нам, аналитикам? Сразу же ограничимся случаем, когда аналитик выполняет оценку “для себя” (т.е. предполагается, что он будет впоследствии заниматься оцениваемой работой).

I. Вариант оценки “снизу”.

Как оценить работы, не закладывая все возможные риски и при этом все же подстраховать себя?

Здесь следует выделить различные ситуации, исходя из которых следует производить оценку.

Знакома ли предметная область и есть ли опыт создания аналогичной документации?

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

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

Если ваши коллеги не смогли вас быстро сориентировать в оценках, то нужно настаивать на необходимости предварительной подготовки концепции решения и согласовании данной концепции с разработчиками, аналитиками смежных систем (в случае, если проект затрагивает несколько систем) и, конечно,  с клиентом. Таким образом, оценивая, вы уже будете понимать, что предстоит реализовать и каковы примерные объемы работ. Кроме того, согласовав концепцию с клиентом, разработчиками и аналитиками смежных систем, вы сможете убедиться, что: во-первых, правильно поняли бизнес-потребность, а, во-вторых, учли все особенности системного ландшафта.

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

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

Используются ли в документации сложные расчеты?

Наличие сложных алгоритмов вычислений и степень того, насколько они изначально известны, -  это очень важный фактор.

Для наглядности начнем с элементарного примера. Представим, что перед вами ставится задача “Рассчитать транспортный налог 2012-2013 года (налог на автомобиль)”.

При такой формулировке, вам потребуется определить формулу и согласовать ее с клиентом.

Если же задача формулируется как “Рассчитать транспортный налог 2012-2013 года (налог на автомобиль). При этом должна использоваться формула: Сумма налога = (налоговая ставка) Х (количество Л.С.) X (кол-во месяцев владения\месяцев в году)”, то трудоемкость задачи сокращается за счет изначально прописанной расчетной формулы, ведь на согласование алгоритмов расчетов с клиентом порой уходит до недели трети суммарных трудозатрат на постановку. В добавок, есть вероятность, что заказчик не знает точно — по каким алгоритмам должны выполняться те или иные расчеты и вам придется выводить их самостоятельно. При этом рекомендуем уведомить свое руководство о наличии риска изменения законодательства, так как в случае его наступления — заказчик будет пытаться переложить всю ответственность за поддержку данных изменений на разработчика.

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

Менеджер проекта: “А чего там оценивать? Там работы на пол часа максимум!”

Есть ситуации, когда менеджер уже всё решил за вас и против вас. Например: «Там быстро, я поговорил с Ваней, — все API уже должны быть реализованы, все данные тебе вернут, осталось только форму нарисовать». Аналитик поддавшись давлению менеджера и согласившись с его оценками, получает, что на деле, API не все реализованы (а некоторые даже и не планировалось реализовывать), данные хранятся с разной аналитикой (например, в одной системе суммарные обороты по всем портфелям клиентов, а в другой — по каждому портфелю отдельно) и т.д. В итоге, аналитик срывает срок, выходит на работу в выходной день и, по сути, винить кроме себя ему некого. В таких ситуациях необходимо проявлять определенную степень стойкости и упорства и настаивать на том, что необходим предварительный анализ на предмет наличия всей необходимой входной информации и т.д.

Нет времени на создание более-менее вменяемой концепции

Если менеджер проекта настаивает на отсутствии времени на подготовку/согласование концепции (типичная фраза “Не дадим оценки сегодня — клиент уйдет к конкурентам!”) и требует так называемую “Экспресс-оценку”, то обязательно необходимо в письменной форме зафиксировать, что это именно предварительная высокоуровневая оценка и после подробного анализа возможно изменение данных оценок как в меньшую, так и в большую сторону (причем корректировка может быть значительной). В противном случае, вам сначала скажут «да, конечно — мы все понимаем и до клиента донесем», а потом как обычно будет «ну мы же клиенту другие оценки называли, реализовывайте в соответствии с согласованными сроками”.

II. Вариант оценки “сверху”.

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

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

1. Аналитик жертвует личным временем и пытается всеми силами вытянуть проект (что, в большинстве случаев, заканчивается либо срывом сроков, либо низким качеством конечного продукта).

2. Аналитик не идет на поводу у менеджеров и все-таки добивается понимания как со стороны менеджера, так и со стороны руководств, что в указанные сроки и трудоемкости невозможно выполнить требуемый объем работ с должным качеством (либо вовсе не уложиться).

Далее либо:

○      принимается решение о выделении на проект дополнительных ресурсов должного уровня (если выделить дополнительно аналитика-стажера/аналитика, не знающего предметную область, то скорее замедлит, нежели  ускорит проект);

○      выделяется необходимый минимум функциональных возможностей, который реализуется качественно и в срок, а весь оставшийся объем работ предлагается доделать вторым этапом в рамках текущего контракта. Но стоит сказать, что склонить все заинтересованные лица (включая и менеджеров, и клиентов) к такого рода компромиссу весьма тяжело — необходимо иметь четкую аргументацию, высокую стрессоустойчивость и определенную долю дипломатических способностей, а желательно и немалые “заслуги” и авторитет в компании.

Вывод

Мы рассмотрели 2 типовых случая оценки требований: оценка “снизу” и оценка “сверху” и проанализировали наиболее типовые ситуации, с которыми может столкнуться аналитик при получении задачи на оценку сроков реализации. Рекомендации по поведению в таких ситуациях, которые мы дали, ни в коем случае не являются “руководством к действию” — это всего лишь обобщение имеющегося у нас опыта и, в любом случае, каждый должен отталкиваться от ситуации и правил своей компании. В любом случае, если вы получаете задач в работу, то вы должны уже применять свои аналитические навыки, а именно узнать:

• Заинтересованных лиц (Кто?)
• Цель (Зачем?)
• Сроки (Когда?)
• Глубину проработки (Какой уровень детализации?)

А далее отталкиваться от полученных сведений.

Алексей Киселев

(akiselev87.wordpress.com), Аналитик, IBS

 

 

 

 

 

Душечкина Екатерина

Бизнес-аналитик, EPAM Systems