Что первично: спецификация, оценка, бюджет или?

45 комментариев
Что первично: спецификация, оценка, бюджет или?
Авторы: Алексей Янчук, Константин Кондратюк Представим, что к вам приходит проект-спонсор, выкладывает перед вами бриф проекта и спрашивает: когда можете сделать, и если нужны деньги - только скажите, деньги не будут проблемой. Почти что мечта, только с чего начать обсуждение будущего проекта:
  • Кто будет писать спецификации? или
  • Что на самом деле и к какому сроку хочет увидеть спонсор? или
  • Какую максимальную цену готов заплатить спонсор за проект?
По правде говоря, все элементы проекта взаимосвязаны. По большому счету, нет особой разницы, с чего начинать обсуждение. Спецификация трансформируется в оценку разработчика, оценка пересчитывается в бюджет. Как правило, первоначально рассчитанный бюджет слишком большой, поэтому идем назад: пересматриваем оценки, меняем спецификации. Поменяли -- прослезились: продукт-то получается вообще никакой. Возвращаемся в начало, и по новой... После нескольких итераций в итоге получаем спецификацию, оценку и бюджет, с которой все согласны. Минус номер один -- игра в такой пинг-понг занимает много времени. Можно ли, если не избежать, то хотя бы сократить временные затраты? Чтобы не получилось, что обсуждали дольше, чем делали. Нет ничего невозможного, хотя "договаривание" заинтересованных сторон это скорее игра, нежели точная наука. Здесь надо полагаться на чутье и умение делать оценки на начальных стадиях проекта. Если стоит цель сэкономить время, стоит рассматривать факторы в порядке их влияния на проект. Например, если бюджеты на разработку и эксплуатацию фиксированы, то планировать проект надо от них. Не имеет смысла тратить силы на написание спецификации, которую заведомо невозможно реализовать. Если стоит цель тянуть время в силу разных причин, то стоит рассматривать факторы в порядке обратном их влияния. Минус номер два в пинг-понге "спецификация-оценка-бюджет-и-назад" в том, что он часто "садит на коня" спонсора или заинтересованные стороны. Поскольку оценки крайне редко пересматриваются в сторону уменьшения, а вносить изменения и дополнения в проект вроде как никто не запрещает, то проект из маленького простого на пару человеко-дней может вырости в большого монстра на пару человеко-лет. Заказчика, которому это надо оплачивать, такой поворот событий вряд ли может устроить. Его претензии вполне можно понять: ведь еще недавно говорили, что проект простой и маленький, надо вот только детали проработать. А после проработки деталей получилось, что проект огромный, сложный и неподъемный. Такая ситуация случается всякий раз, когда разработчиков просят выдавать оценку по требованиям, сформулированным на скорую руку. Такая оценка будет всегда заниженной, подчеркиваем - всегда, потому что разработчики в лучшем случае забыли или не учли половину задач. А напомнить им об этом может только более-менее полная спецификация вместе с качественно проведенным планированием. В нашем опыте следующий подход почти всегда дает результат и бережет нервы:
  1. Заказчик формулирует идею в любой ему понятной форме;
  2. Обсуждается идея на уровне принципиальной возможности или невозможности, и на какой квартал ее можно запланировать;
  3. Заказчик прорабатывает требования и уточняет детали. Происходит обсуждение новых деталей, чтобы понять, не стала ли задача гораздо больше;
  4. Бизнес-аналитик пишет спецификацию. Задача спецификации - проработать вопросы как бизнеса, так и разработчиков о том, как целевое решение должно себя вести в различных ситуациях, ответить на возникающие вопросы;
  5. Заказчик подписывает спецификацию;
  6. И только после этого разработчиком официально объявляются: ресурсы, дата старта, дата начала фазы тестирования, дата запуска в эксплуатацию.
Будет ли заказчик ждать до самого конца, чтобы услышать дату (бюджет и т.д.) -- ну когда же его решение будет готово? Естественно, нет. С изрядной долей вероятности будет очень настойчив, чтобы разработчики чем скорей "разродились" ей. Что делать тут разработчику? Все зависит от того, какие отношения сложились между заказчиком и исполнителем. Наш опыт показывает, что более-менее адекватную оценку можно дать, когда в спецификации полностью проработаны все ключевые вопросы, а это как привило значит, что спецификация закончена на 80%. Давая оценку раньше, вы всегда рискуете либо выдать слишком завышенную, либо, что более вероятно, слишком заниженную. Мы сами стараемся избегать называть любые даты или цифры раньше, чем спецификация готова на эти 80% -- даже когда работаем с теми заказчиками, с которыми сотрудничаем годами. Остался один вопрос: что делать бизнесу в случае, если в конечном итоге разработчики не могут сделать проект в желаемых рамках, будь то календарь, бюджет или функциональность? Эти и другие вопросы будут рассмотрены на тренинге "Управление ИТ-проектами" в Минске 19-20 мая 2012 г., который проводится командой iTrainings.ru в партнерстве с компанией Itransition. Скачать программу и зарегистрироваться на тренинг вы можете здесь.

Горячие события

Конкурс EY Entrepreneur Of The Year 2020
31 мая — 31 мая

Конкурс EY Entrepreneur Of The Year 2020

ISsoft Insights 2020
6 июня — 6 июня

ISsoft Insights 2020

Минск
GoWayFest 4.0
11 июля — 11 июля

GoWayFest 4.0

Минск

Читайте также

«Прошу терпения и понимания». Гендиректор Itransition написал сотрудникам о кризисе
«Прошу терпения и понимания». Гендиректор Itransition написал сотрудникам о кризисе

«Прошу терпения и понимания». Гендиректор Itransition написал сотрудникам о кризисе

32 комментария
Антикризисные меры: в A1QA оклады урезают на 20%
Антикризисные меры: в A1QA оклады урезают на 20%

Антикризисные меры: в A1QA оклады урезают на 20%

Коронакризис, который предрекают всем отраслям, уже коснулся белорусского ИТ. CEO компании A1QA Светлана Правдина объявила об антикризисных мерах в компании. 
108 комментариев
Председатель совета директоров Itransition: «Задержание главы инвестфонда Baring Vostok не скажется на текущих планах компании»
Председатель совета директоров Itransition: «Задержание главы инвестфонда Baring Vostok не скажется на текущих планах компании»

Председатель совета директоров Itransition: «Задержание главы инвестфонда Baring Vostok не скажется на текущих планах компании»

1 комментарий
Белорусская ИТ-компания Itransition привлекла стратегического инвестора
Белорусская ИТ-компания Itransition привлекла стратегического инвестора

Белорусская ИТ-компания Itransition привлекла стратегического инвестора

6 комментариев

Обсуждение

26

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

Я негодую!!

0

Есть! И не мало.

0

Чисто шкурный интерес:
- Можете привести такие конторы? Интересует конкрето PHP :-)

Anonymous
Anonymous Project Manager в EPAM
0

Не все проекты можно сделать по Agile (к сожалению).

agentcooper
agentcooper PM в SK hynix memory solutions Eastern Europe
0

Не все. Но почему к сожалению ? :)

Михаил Дубаков
Михаил Дубаков Writer в Fibery
2

Ну, мы.

1

а че? на аджайл свет клином сошелся?
попробуйте погуглить что то типа 'anti-adgile'.

1

У нас есть отдельные Аджайл коучи, но специализированных контор нету.
В России это ScrumTrack (Асхат Уразбаев и Никита Филипов). В Украине это ScrumGuide.
В Беларуси рынок совсем не большой и он не занят.

amok
amok Team Lead в Ergalio
0

Так это, как аджайл рекомендует оценивать проекты?

agentcooper
agentcooper PM в SK hynix memory solutions Eastern Europe
1

Техники оценки проектов обычно не привязаны к фрэймворкам управления проектами и моделям/методологиям SDLC. С другой стороны fixed price проекты, где оценка жизненно важна для исполнителя, вообще слабо совместимы с agile.

agentcooper
agentcooper PM в SK hynix memory solutions Eastern Europe
1

Извиняюсь, конечно, за резкость, но, ребята, при подобном уровне понимания PM вам не по 2 800 000 (с НДС) за тренинг стоит собирать, а для начала пару книжек прочесть. Не уверен выдержал бы ли я 2 дня подобной ахинеи, если бы мне эти 2 800 000 (с НДС) заплатили.

0

в данном случае совершенно не позиционирую себя, как специалиста по управлению проектами, но в реальной жизни данная схема развивалась бы так:
1. ок
2. ок
3. Заказчик просит назвать сумму. Вы пытаетесь вытянуть из заказчика детальные требования второй рукой уже набивая какую-никакую спецификацию. Четких требований вытянуть не удается (заказчик ещё с ними вообще не определился или ему на это надо время), но заказчик настойчиво продолжает просить сумму. Хоть какую то. Вы говорите, что без 80% спецификации ничего не получится.
4. Вы потеряли заказчика.
Обучиться этим и другим fail-ам вы сможите на тренинге... и далее по тексту...

agentcooper
agentcooper PM в SK hynix memory solutions Eastern Europe
0

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

Михаил Дубаков
Михаил Дубаков Writer в Fibery
2

Плюсую.

Максим  Гулевич
Максим Гулевич Дизайнер в EPAM
3

%) снял с языка, плюсану, пожалуй

Anonymous
Anonymous работаю в Digiteum
10

Плюсанула всех по цепочке

amok
amok Team Lead в Ergalio
0

Я б сказал, что аджайл хреново работает с распределёнными командами и с командами, где много джуниоров. Ещё, на проектах, где часто меняют людей. Ещё на больших проектах, которые очень давно вышли на стадию суппорта и "отцы основатели" недоступны, но фичи добавлять и баги фиксить надо. Короче, на многих аутсорсинговых проектах, которыми наши конторы занимаются )

2

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

Максим Дешкевич
Максим Дешкевич Project Manager в FirstBeatMedia
1

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

Максим  Гулевич
Максим Гулевич Дизайнер в EPAM

Комментарий скрыт за нарушение правил комментирования.

п. 2.3.4 Пользовательского соглашения — https://dev.by/pages/agreement.

Комментарий скрыт за нарушение правил комментирования.

п. 2.3.4 Пользовательского соглашения — https://dev.by/pages/agreement.

Михаил Дубаков
Михаил Дубаков Writer в Fibery
2

Тут есть одна проблема. Программистам надо указать сторону, в которую писать код. А то ведь напишут не в ту сторону, придется переписывать. Для этого конечно нет смысла писать огромные документы с требованиями, устанавливать жестко сроки, и делать все, что предлагают выше. Но как-то же надо обсудить, что мы строим? А? Веб приложение для детей или мобайл сошл нетворк.

А человека, который на вопрос "как думаешь, когда сделаешь?" хочет уебать с ноги, я бы уволил в ту же секунду, как только определил это желание. Ну или отправил лечиться от невроза в крайнем случае. Если у человека такое желание возникает, значит он почему-то не уволился сам гораздо раньше, еще до того, как оно возникло (были же тревожные звоночки, нет?). Почему не уволился? Чего он терпел до предела? Я не могу найти вменяемого ответа на этот вопрос.

Комментарий скрыт за нарушение правил комментирования.

п. 2.3.4 Пользовательского соглашения — https://dev.by/pages/agreement.

Михаил Дубаков
Михаил Дубаков Writer в Fibery
2

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

11

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

Одни манагеры в ай-ти у нас все в белом. Нихрена не знают, нихрена не умеют... и нихрена не делают видимо! Так да?! Поэтому пиши пропало? :)

Михаил Дубаков
Михаил Дубаков Writer в Fibery
2

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

1

Интересно, что в Valve (которые создали Half-Life, Counter Strike, Steam, Left4Dead2, Portal2) тоже нет менеджеров - http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdf . Вот что они пишут про менеджеров:

Manager—The kind of people we don’t have any of. So if you see one, tell somebody, because it’s probably the ghost of whoever was in this building before us. Whatever you do, don’t let him give you a presentation on paradigms in spectral proactivity.

Признавайтесь, кто у кого украл идею о бесполезности менеджеров? :)

Михаил Дубаков
Михаил Дубаков Writer в Fibery
1

Мы не крали. Про valve не знал. Хорошая компания. Спасибо за линк, прочитаю. Выглядит круто.

1

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

0

Это не ново. В Scrum тоже нет менеджеров, скрам мастер - не PM.

Михаил Дубаков
Михаил Дубаков Writer в Fibery
2

В скрам-то нету, но в компаниях, где внедряют скрам, есть...

0

Valve — не просто продуктовая компания. Valve полностью владеет IP на ВСЕ свои продукты, что очень большая редкость в геймдеве. Кому интересно — может поискать информацию о том, как Гейб сотоварищи выдирали зубами интеллектуальную собственность на Half-Life.

Мне лично кажется, что Valve просто не может себе позволить иметь менеджеров.
Как минимум по двум причинам: 1) они очень хорошо помнят, что произошло с Monolith и 3DRealms и 2) люди, которые являются авторитетами для тех, кто прошел собеседование в Valve — тупо не работают "на дядю" вообще; уровень не тот, и не столько финансовый.
P.S. Очень хочется верить, что в Valve действительно понедельник, который начинается в субботу — а не лемовский Эдем.

0

А что в разработке делает менеджер? зачем он нужен?

0

Бодишоп без пиэмов — деньги на ветер!

0

Я думаю, что имелась ввиду частая ситуация периодического "дёрганья за лацкан пиджака", То есть когда в периодичностью в минут двадцать подходит менеджер со щенячьим взглядом и мычит "ну как там у нас дела, а какие твои оценки, ну когда сделаем?!". При этом у него была оценка, скажем, в 40 часов, а приходит он через 3 часа после начала разработки и просит с надрывом "хоть что-нибудь сегодня выкатить".

Да. хочется. и не только ногой.

21

>>а если это еще и менеджер будет делать, то все, пиши пропало.
>>Прораб на стройке четко знает в какой срок и как он со своими рабочими положит из кирпичей стену.

ИМХО, все зависит от менеджера как такового, его опыта и взаимоотношений в команде, в частности. К примеру, менеджер может давать оценки, если это "стандартные / потоковые" и уже единажды пройденные задачи либо, если менеджер обладает необходимыми знаниями для приведения подобных оценок. Почему бы и нет? Тут, более важно, кто будет нести ответсвенность за ошибки в оценке. Полномочия и ответсвенность хотелось бы, в идеале, оставилять всегда на одном уровне.

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

0

>>ИМХО, все зависит от менеджера как такового...

Работать в конторе с интститутом PMов, где ты не решаешь, какие таски себе взять, где вы вместе не обсуждаете, какую архитектуру сделать, а PM говорит "нужно делать вот так вот", да просто где не атмосфера того, что мы делаем это вместе - там работать НЕ ИНТЕРЕСНО. Уныло.

-1

Вообще, управленцам, которые читают эти каменты, хотелось бы посоветовать почитать ликбез http://oz.by/books/more10188514.html
Проблема со скрамом, как его преподносят, в том, что все говороят про то, какие есть роли в скраме, какие есть практики, но ни кто не говорит _почему_ скрам именно такой. Почему обязанности между ролями распределены именно так, что дают 15 мин митинги (отделение бизнес оунера/ скрам мастера / любой другой роль или артефакт скрама), и какие потери несет проект при отказе от него, какие риски. Не объясняется, если не ошибаюсь и в самой книге Кена Швабера, хотя там все не просто так.
Вот в приведенной книге, кажется, этот пробел восполняется.

Скрам ОХУЕНЕН для меня, как для разработчика, и, я думаю, ОХУЕНЕН для компании, а если компания не может применить его у себя - нужно просто учиться. Так что, господа управленцы, не поленитесь вникнуть хорошо и ответственно.

agentcooper
agentcooper PM в SK hynix memory solutions Eastern Europe
0

Дорогой коллега, из вашего пламенного послания смысл имеет следующая часть:

>Скрам ОХУЕНЕН для меня, как для разработчика

- потому как описывает ваши личные, безусловно интересные и заслуживающие уважения, переживания. Все остальное - чепуха примерно такого же уровня, как и чепуха коллег в обсуждаемой статье - только находится на противоположном конце спектра околопиэмской чепухи. Что конечно простительно (и даже минус вам не мой) - потому что вы не пиэм и не предлагаете платить вам 2 800 000 (с НДС). Но пафос все же поубавьте и начните ликбез с себя - лучше всего вот с этого http://www.amazon.com/Balancing-Agility-Discipline-Guide-Perplexed/dp/0321186125 .

Михаил Дубаков
Михаил Дубаков Writer в Fibery
11

А я осмелюсь предложить в качестве стартовой литературы пиплваре http://www.amazon.com/Peopleware-Productive-Projects-Second-Edition/dp/0932633439

agentcooper
agentcooper PM в SK hynix memory solutions Eastern Europe
0

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

0

Я не считал, что Скрам - это всемогутор. Меня просто удручло, что не испольщуются сильные стороны Скрама.

agentcooper
agentcooper PM в SK hynix memory solutions Eastern Europe
0

Скрам можно использовать не всегда. Пока дойдете до Боэма почитайте недавнюю дискуссию - я излагал свои взгляды в том числе на его область применимости. http://dev.by/blog/45506

1

Сэнк`ю Обязательно почитаю.
Да, пафоса действительно слишком много..

0

че-то не понял из текста... в первом случае идет пинг-понг, это понятно. а во втором случае просто все пишет бизнес-аналитик каким-то чудом без всякого пинг-понга.
это хитрый спам аналитиков?)