«Аутсорсинг головного мозга». Или всё-таки можно научиться совмещать гибкую разработку и fixed-price?

Кажется, что гибкая разработка, в частности приёмы и советы каркаса Скрам, идёт вразрез реалиям мира аутсорсинга и fixed-price проектов. Это не так.

Мне часто говорят: «Ну да, конечно, это всё прекрасно работает у вас там в Европе в продуктовых компаниях. У нас же здесь — никак. Мы работаем в аутсорсинге». Это заблуждение. Вернее, аутсорсинг, конечно, можно использовать как оправдание своей некомпетентности. Но это ещё никому не помогало.

Fixed-price проекты, я считаю, это отличная возможность отточить своё мастерство менеджмента. Scrum, к слову, родился как раз в таких проектах. Если у вас в проекте не ограничены средства, зачем тогда вообще что-то менеджерить? Пусть течёт как течёт. Так что fixed-price и agile — они как раз очень даже мило уживаются, поддерживая друг друга. В противовес fixed-scope проектам, которых на самом деле не существует. Вернее, scope можно пытаться ограничивать... Но это идёт вразрез законам природы и всемирного тяготения к изменениям.

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

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

И эта тема явно болезненная, судя по яркой реакции на мой недавний провокационный пост:

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

Составление контракта — театр абсурда, в котором ничего от менеджмента

«Предсказания сложны, особенно, когда речь идёт о будущем» Нильс Бор, квантовый физик и игрок датской сборной по футболу

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

И так. По порядку. Вы выиграли тендер (не приведи бог!), ну или — что чуть лучше — уговорили заказчика доверить вам разработку его бесценного (но ещё несуществующего) продукта за оговоренную сумму денег. Ну или же переписать старую систему на новые рельсы. Так что вместе с фиксацией суммы контракта (и вашей маржи), вы так или иначе оговариваете и сам фронт работ.

Это ок. Пока всё норм. Как вы это делаете — меня не сильно волнует:

Вы прикидываете объём проекта, расписывая спецификации больших фич... На это уходит, скажем, две недели. Для этой фазы ранее вы снимали с проектов людей. Но так как это оказалось «неэффективно», теперь у вас есть целый отдел аналитиков, которые очень «точно» оценивают объёмы проектов, которые никогда сами не делают (услышьте мой циничный смешок). Вы сравнили проект с имеющимися историческими данными по схожим проектам (очень, кстати, отличный метод, без цинизма). Поделили годовой проект на (под)проекты чуть поменьше (тоже очень разумный шаг, без иронии). Умножили на выстраданный опытом «менеджерский коэффициент» (ваше дело). Посыпали волшебным порошком (не зря этому учат в PMI = Project Magical Institute). И э-ге-гей — подписываете контракт!

«Банзай! Как-то выплывем!» — говорите вы себе.
«А-ага-га!» — лукавит вам эхо.

Я не углубляюсь в то, как вы делаете расчёты проекта. Это вне цели данной статьи (есть варианты ухода от подобного рода lose-lose контрактов, но эта статья не об этом). Я хочу здесь рассмотреть вариант «жёсткого аутсорсинга, как он есть, после факта составление нереального договора на цену и объём работ». Типа:

«Сделайте мне очень много работы за очень мало денег и времени» — говорит заказчик.
«ОК, сэр!» — крестимся мы, закладывая буфер меньший, чем у конкурентов, и всё-таки достаточный, чтобы как-то выплыть.

Все мы понимаем, что определение стоимости и объёма проекта до его начала — это самое нелогичное действие из всех, к которому нас вынуждает действительность проектной деятельности по схеме «fixed scope». Почему? Да потому что в этот момент времени мы знаем как раз меньше всего об этом проекте.

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

#ШОТЕПЕРЬ?

Customer collaboration over contract negotiation

«Как задержать годовой проект на год? По одному дню в день» Кто-то из великих

Ха, а вот теперь начинается то, что я люблю и называю «реальным менеджментом». Всё, что вы делали до этого — это жонглирование тупыми пластмассовыми ножами — трюк для тех, кто хочет поверить в сказки. Менеджмент ещё не начинался.

И он не про то «как нам сделать весь скоуп вовремя, внутри отведённого бюджета и с заложенной маржой» — это для любителей PMBoK. У всех школ должны быть свои поклонники. Представьте, как вам будет сложно конкурировать на рынке, когда все проекты успешны! Нет, нам с вами это не нужно. Так что пусть традиционные менеджеры действуют традиционно — тратят месяцы на оттачивание деталей договоров, занимаясь, так сказать «premature scope management». Рисуют цветные диаграмма Ганта и нити накала проектных страстей. Расписывают риски и делят ресурсы.

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

Что же такое реальный менеджмент? Это значит каждый день делать лучшее из возможного, с учётом строгих рамок сроков, денег, людей и возможностей.

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

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

Что же такое «делать лучшее из возможного»? Как минимум:
— то, что заложит фундамент доверия между клиентом и нами;
— самое важное для самых главных пользователей (key user journeys);
— самое рискованное с точки зрения технологий (fail fast, fail often);
— всё, без чего вообще нельзя выйти в продакшн (minimum viable product).

А что же со всем остальным, что прописано в опечатанном документе с требованиями по проекту? Советую забыть обо всём остальном. И не тратить на это ни секунды. Любая потраченная секунда на неважную работу, забирает секунду, которую вы могли бы потратить на важную. Кеп очевидность? Возможно.

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

Как же понять «что важно и без чего нельзя»? Очень хороший вопрос. Скорее всего, без вовлечения заказчика и их пользователей — никак. Увы. Нет, вы-то, конечно, можете дуть щёки и утверждать, что фича «Z» должна быть уже в первом релизе продукта. Это хорошее предположение. Но если это окажется не так, в суде ваша былая уверенность не поможет.

Что же поможет в суде? Думаю, уже ничего. Важно до него не довести!

Но как?
— Устойчивые отношения с заказчиком — ваш козырь. Его ничем не побить.
— Формируйте доверие к вам путём постоянной демонстрации того, что вы каждый день делаете лучшее из возможного для продукта.
— При этом нельзя переоценить навык прозрачной визуализации прогресса и расходования бюджета (об этом будет следующая статья).

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

Это и есть тот самый «Agile mindset». Тут не с чем спорить. Бери и делай.

На «скра» начинается, на «м» кончается

Как же это делать?

Первое: научиться таки выпускать софт итеративно-инкрементально.

Когда заказчик видит работающий продукт, это существенно снижает давление в проекте, уменьшает внимание и придирки к «спецификациям». Ничего не налаживает лучших отношений между вендором и заказчиками, как «прокликивание сделанных на прошлой неделе фич». Это должно делаться регулярно. Так часто, как возможно. Но не реже раза в две недели. Do Scrum by the book.

Если вы, как вендор, не умеете выпускать рабочий продукт с регулярностью от нескольких дней до пары недель — вы занимаетесь не тем бизнесом. Вы дилетант и прохвост. Сорри, я обещал без холиваров, но тут уж никак по-другому не скажешь. Go back to school. Никакие контракты вас не спасут. Учитесь (это долго). Ну или же наймите трёх толковых программистов (не больше), каждого со стажем и знанием как минимум трёх различных платформ (вам нужны широкопрофильщики) и избавьтесь от всего остального «балласта». Некоторые программисты в десятки раз более продуктивны других (как следствие, другие в десятки раз менее продуктивны). Вдумайтесь в эти цифры. Поэтому на деле закладка никаких коэффициентов и буферов в бюджеты и сроки не помогает.

Вы или умеете выпускать продукты, или нет? Это навык, который нельзя переоценить, скрыть или выторговать. Это и есть философия Scrum.

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

Так, «Sprint Review» в Скраме — это крайне многомерная практика, недооцениваемая многими. Одним её измерением является возможность строить отношения с заказчиком. Ни раз и ни два. А постоянно.

К примеру, задавая заказчику вопрос сразу после демо текущего билда продукта: «Какую фичу нам сделать на следующей неделе X или Y?», вы вовлекаете заказчика больше, чем любой притянутый за уши контракт или менеджер продаж с навыками полтергейста. Это работает лучше любого корпоратива с хреновухой в качестве аперитива, экскурсий по вашему городу или похода в баню.

Приоритезируя, заказчик — уже на вашей стороне. Он видит продукт, работает с ним, начинает понимать невалидность ранних требований, генерирует новые (лучшие!) идеи. С этого момента — заказчик ваш, а вы его. Вы нужны друг другу. И контракт больше не разделяет вас. Он уходит на второй план. На первый план выходит продукт.

(Это всё, конечно, при условии, что вы имеете доступ к представителям заказчика, которые реально заинтересованы в продукте. Если нет — бегите прочь. Но лучше ищите на той стороне того, кто платит. Кто отвечает головой за возврат инвестиций. Там точно есть такой человек, и ему ой как не всё равно)

Но как же сам контракт? Оставьте его юристам. Ваша задача не довести дело до их вовлечения.


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

И всё это внутри всё тех же fixed-price продуктов.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
LinkedIn

Схожі статті




73 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

Очень хотелось бы почитать.

Весьма занимательное выступление на тему.
youtu.be/eSpfS9U66bg
«Cлава Лукьяненка (Wargaming) — Ценные уроки, извлеченные из провалов в управлении разработкой игр»

вижу в этом мире скопилось много обиженных «скрамом» людей. очень жаль.. и как минимум половина «озлоблённых» (как видно из комментариев) работающий скрам в глаза-то и не видела.

жаль. реально. ибо классная команда, тесно работающая с заказчиком — это прекрасное зрелище.

сходите может в гости в компании, где всё в порядке? поговорите с людьми, у которых есть позитивный опыт?

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

решать вам.

жаль. реально. ибо классная команда, тесно работающая с заказчиком — это прекрасное зрелище.
Жаль реально такое практически нереально собрать включая «тесно работающего заказчика» включительно.

А есть возможность сходить в гости в компанию где все в порядке? Я бы сходил. Мне очень нужно.

на троллинг больше не отвечаю.

Все складно, если мы говорим о проектах на 3,5 погроммиста длительностью до 6 месяцев.
Вот представим у вас проект на 2 года с ежеквартальным ревью стиринг комитетом. Вы что им будете рассказывать когда за 30% бюджета выполните 10% (причем их не будет волновать какие-то ваши графики у них свои будут :) ) работы потому что «у нас fixed-price а не fixed-scope»? Про скрам эти суровые ребята слушать не будут и мартинчик вы с ними хрен попьете. Скорее всего просто убежите с проекта с криками, что заказчик дебил и не понимает как надо работать, и вас всего такого талантливого тоже не поняли. (Видал я такие случаи и не раз)
Вместо сертификации по аджайлу уже давно пора вводить сертификацию по common sense.

Все мы понимаем, что определение стоимости и объёма проекта до его начала — это самое нелогичное действие из всех, к которому нас вынуждает действительность проектной деятельности по схеме «fixed scope». Почему? Да потому что в этот момент времени мы знаем как раз меньше всего об этом проекте.

ЛОЛ

Как раз реально крупные проекты только по Скраму и можно успешно делать. Я лично участвовал в проекте миграции огромной системы обработки транзакций в банке (ежедневный объем сделок — около 2 триллионов USD) с бюджетом $60M (в пике было до 120 человек в 5 локациях от Нью-Йорка до Гонконга). Первые две попытки сделать этот проект с предварительным планированием fixed scope & budget успешно провалились, после чего решили пилить итеративно, начиная с самых рисковых business flows. Пилили, в итоге, 6 лет вместо изначально оцененных методом «с потолка» пяти, но успешно мигрировали все, причем в production система была параллельно со старой через девять месяцев от старта проекта (символично).

Это исключение из правила, скрам фейлит крупные проэкты с вероятностью 99%.

если у вас проект на два года, но вы что-то делаете не так.

с троллингом пойди в форум.

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

Как правило 99% кастомеров, которые заходят в Украину в случае аутсорса, здесь не за unuique value proposition или технической экспертизой, которую они не могу взять в другом месте, а для того, чтобы сэкономить выделенный бюджет. К сожалению, мне пока не встретилось ни одной value driven компании в аутсорсе, 99% это financialy effective организации, их главная задача — максимизация прибыли. Качество, ценность продукта вторичны.

Я выступал в роли ПМа на нескольких проектах, где присутствовали гибкий и прозрачный процесс, регулярные демо с аксептансом, радостная похвала клиента, time and material контракт без оговоренного бюджета и скоупа. Мечта, скажите вы?
Это все равно не убезопасило от ситуации, когда клиент решил, что имеет право на большую «скидку», потому как бюджет заканчивается, а работы еще много впереди. «Мы потом закажем еще один проект, посоветуем друзьям и тд».
Не имели никакого эффекта в данных случаях рассказы о discovery process, estimations it just a promise.. качественный присейлз и гибкий контракт.

Мораль 1. Задача сейлзов, ко всему прочему, понять настоящие мотивы потенциального клиента, знать бюджетные ограничения, изучить его историю с другими аутсорсерами. Это бизнес риск и кост/шедул риски, которые более важны, чем технологические, социальные или другие риски команды или проекта.
Мораль 2. Shit happens. Гарантии только в обувном магазине. Still no silver bullet, sorry ¯\_(ツ)_/¯

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

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

но на моём опыты (и мой врождённый идеализм меня тут поддерживает) — правильная работа с клиентом посредством «реального менеджемента» (как я описал в статье) сильно занижает негативное влияние клиента на ваши с ним отношения.

Как правило 99% кастомеров, которые заходят в Украину в случае аутсорса, здесь не за unuique value proposition или технической экспертизой, которую они не могу взять в другом месте, а для того, чтобы сэкономить выделенный бюджет. К сожалению, мне пока не встретилось ни одной value driven компании в аутсорсе, 99% это financialy effective организации, их главная задача — максимизация прибыли. Качество, ценность продукта вторичны.

👏 Я бы только поменял «максимизацию прибыли» на «минимизацию расходов». Очень многое из того, что делается в аутсорсинге, делается из бюджетов департаментов, которые являются cost centers и нам речь о прибыли не идет.

... timeo Danaos et dona ferentes.
Беда всех статей о Скраме, как и беда всех эджайл сертифайд скрам мастер коучеров в том, что они предпочитают выбросить из уравнения проекта всё, что только можно выбросить. Это как если бы все пилоты всегда исходили только из того, что атмосфера бывает только ISA и больше никакая другая. Попрыгав между собственными галерами, коучи яростно начинают учить других, как проваливать 70% проектов. И всё это только на чистом ванильном скраме. Попахивает нафталином 2000-ых, когда все так же безоговорочно призывали верить RUP-у.

Автор явно предлагает «прокинуть» клиента, подписав контракт на fixed price/fixed scope, подставить владельцев или контору, а самому же попытаться сделать хорошее лицо при плохой игре и быстро перевести проект на рельсы эджайла. В случае провала можно уволиться, чё уж, разгребать то все равно владельцам.

Почему нет ни одного упоминания о том, что действительно имеет значение, а именно presale и адекватной продажи клиенту как процесса, так и пресловутого треугольника, оговорив, что в нем и как можно крутить? Почему не описано ни одного сценария «что если»? Где практики работы с рисками?

Не спорю, статтья отличная, и поможет обернуть еще несколько неопределившихся ПМов в веру великого и могущественного, но не стоит ли прислушаться к старику Попперу и предположить, что в красоте «чистого» скрама таится множество недочётов, которые уважаемое комьюнити продолжает скрывать?

Верно, но не в чистом же виде.

Воооот, жму руку как, чётко сказали. Почему тогда о scrum так не говорят?

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

если вы не применяете что-то в чистом виде, то зачем это вообще как-то называть тогда?

называть здравым смыслом

“common sense is not that common” как известно.

это всё софистика, вы прекрасно поняли о чем я.

не видел хороших реализаций. как у коммунизма.

Когда у меня на собеседовании спрашивают, работал ли я по скраму, всегда говорю работал в проектах где люди говорили что у них скрам

хотя бы честно. но чести эти делает.

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

ищите дальше. такие проекты-команды-компании есть.

я сожалею о вашем опыте.

пришлось зайти на википедию (латынью владею не в совершенстве): en.wikipedia.org/...o_Danaos_et_dona_ferentes

к тому же «gift» — по-немецки «яд».

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

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

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

уж не знаю, как это сказать по латыни.

«по-латыни» — вроде через дефиз.

А «дефис» — вроде с «С» ;)

Just kidding

блин. точно!

Благодарю за ответ. Оторванность сейла от менеджемента — одно из самых невероятных зол, которые можно вообразить. Выходит, что клиенту сформированы одни ожидания в процессе продажи, дальше проект передают ПМу и вот тут начинается «а на самом деле будет по другому, а то всё была фигня для юристов». Этой ересью грешат едва ли не 90% отечественного аутсорса и заказной разработки.

согласен полностью.

но статья о том, как решать проблему уже после сейлов. конечно же, root cause — глубже.

Почему нет ни одного упоминания о том, что действительно имеет значение
Потому что аффтар не достиг еще даже начальной компетенции.

Алексей, чем же опять PMBoK не угодил? Плоха та статья про скрам, где не пнут PMBoK. «осыпали волшебным порошком (не зря этому учат в PMI = Project Magical Institute)» — это о чем? «как нам сделать весь скоуп вовремя, внутри отведённого бюджета и с заложенной маржой» — это для любителей PMBoK" — хороший вывод, кстати. Правда, на чем он основан, не ясно. PMBoK о таком не говорит. Он, кстати, как вести проекты тоже не говорит, ибо он не стандарт, а свод знаний. Ну это уже такое, игры разума на фоне терминологии.
А говоришь — пора взрослеть, без холиворов ;).

Давайте чуть дальше, чем заказная разработка ПО, выйдем, а? Аутсорс и продуктовка — это та же заказная разработка, только заказчик разный. Давайте на уровень проектов, где софт — только одна из составляющих: где есть подрядчики, где софт пилят команды разных компаний, «железо» поставляет третья, сети кладет четверая. Где интеграция софта разных вендоров занимает недели, и отвечает за это один человек. Тот, который с волшебным порошком ;).

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

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

Ну и т.д.

Так что «Мы же с вами погрузимся в реальное управление проектами и, причём, сразу» пока, похоже, откладывается ;).

Аутсорс и продуктовка — это та же заказная разработка, только заказчик разный

уважаемый Maksym, в моём определении:

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

Алексей, спасибо за интересную статью, будем ждать продолжения. Я видел такую наглядную парадигму когда «железный трегольник» переворачивался вершиной вниз и превращался в бокал для мартини одной строной которого было время, а другой деньги и он заполнялся коктелем «value». :-)
Еще, IMHO, возможно проблема в том что Scrum не дает готовых рецептов о риск менеджменте и тп., отсюда постоянные вопросы о том, как управлять риском зависимости от ключего персонала, например. Как сказал кто-то из авторов «Scrum is simple, but not easy» :-)

то, что скрам не даёт решений — это не проблема.

если бы он их давал для каких-то проектных контекстов, то по определению они бы не подходили для всех остальных.

Все так. Бюджетирование имеет смысл. Пускай Fixed Price, но не Fixed Scope, и тем более не одновременно, нужно это фиксировать в контракте. Иначе будем заказчика к этому не прозрачно подводить, путем задабривания демками и надеясь, что потом уже ему не будет от нас куда деться. Так же для него можем зафиксировать, что имеет шансы на выпуск, что вероятно попадет и что абсолютно точно не возможно. Expectation management.

Скорее наоборот ))) что точно не попадет, что вероятно попадет и что имеет шансы.

Это всё, конечно, при условии, что вы имеете доступ к представителям заказчика, которые реально заинтересованы в продукте. Если нет — бегите прочь. Но лучше ищите на той стороне того, кто платит. Кто отвечает головой за возврат инвестиций. Там точно есть такой человек, и ему ой как не всё равно
Зачастую, на «той стороне» сидит IT-менеджер заказчика, который костьми ляжет, чтобы не допустить вендора к бизнесу. Ему нужно успешно распилить бюджет и получить повышение, а не вопросы «а нафига нам эти дорогие онсайтные чуваки, если аутсорсеры делают не хуже?». А если бюджет на IT у заказчика измеряется миллиардными суммами, то заставить себя «бежать прочь» очень тяжело.

Сергей, ты очень прав.

система может быть сложной:
business заказчика <-> IT заказчика <-> IT подрядчика

в этом случае «IT заказчика» является как бы заказчиком для «IT подрядчика». но это лишь по контракту. реальным же кастомером для подрядчика является «business заказчика» и вот именно с ними и нужно строить мосты путём вовлечения в процесс.

и вот как раз это и есть на мой взгляд чуть ли не самый главным момент, который подрядчик разумный (vendor sapiens) должен вложить в контракт: доступ к телу кастомера.

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

Леша, не в обиду будет сказано, но ты, по-моему, неправильно понимаешь миссию ITO-бизнесов. Это не «делать успешные продукты», а «предоставлять клиенту качественный сервис по разработке ПО». Ну, скажем, ты приходишь в ресторан, заказываешь там деруны с грибами, борщ с пампушками, котлету по-киевски с жареной картошкой, и еще пирожное на десерт. А тебе официант начинает рассказывать, что ты и так жирный, и тебе лучше, кроме салата и бульона, ничего больше не брать. Ресторан так не сделает никогда, у него бизнес не в консультировании клиентов по вопросам здорового питания, а в приготовлении еды согласно заказа, пусть на этом маржа и в три раза ниже.

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

«Я не даю взаймы они не торгуют семечками» (к) (тм)

предоставлять клиенту качественный сервис по разработке ПО

а у вас что, делание успешных продуктов не входит в спектр услуг?

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

Проверено на своем опыте! Меня тоже, как менеджера, в самом начале проекта напугала формулрировка, что проект будет фиксед прайс но заказчик (конечный заказчик, а не компания с которой у нас подписан контракт) хочет гибкую разработку. Все было по классике, как и описано в статье выше, мы оценили фичи, написали доку, утвердили объем работ, составили расписание проекта, описали риски и поехали...
И все получилось, вовремя и в срок. Да мы не использовали СКРАМ, так как небыло для этого возможности но мы смогли в самом начале:
• Установили человека, который принимает ключевые решения на стороне клиента и несет ответсвенность за проект — это упростило и ускорило решение сложных или спорных вопросов
• Формализировали работу с посредником — сообщили ему что мы будем работать с конечным клиентом на прямую избегая «скользских» моментов и будем держать посредника в курсе
• Зная конечную дату проекта +/- проект был разбит на 2-х недельные спринты (хотя и разной протяженности по дням) — это помогло отслеживать процесс
• Было составлено расписание еженедельных встречь для отчетности, с менеджерами компании посредника — это дало прозрачность в отношениях (мы работали первый раз) и показало, что мы действительно разбираемся в том, чем занимаемся.
• Была введена демонстрация готовых результатов после каждого спринта — это помогло вовремя изменить структуру приложения и отойти от первоночальной концепции без ущерба для сторон.

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

Отличная статья! Согласен практически со всеми пунктами. Добавил немного своих мыслей и наблюдений по этому поводу: xpinjection.com/...t-mindset-in-outsourcing.

нужно может тогда растить, а не руководить?

А вот и ещё один комментарий с клона статьи на www.krivitsky.com

Beaver Green (Wednesday, 23 November 2016 15:29)

На ДОУ меня коментить не пускают — спрошу тут. Надеюсь ответ напишите там.
Вы правильно уловили стиль менеджмента не fixed-price проекта в типичном аутсорсе:
«Если у вас в проекте не ограничены средства, зачем тогда вообще что-то менеджетить?»
Именно такое я видел на 80% «бесконечных» проектов где клиент платит за человеко-часы.
А вот на редких fixed-price проектах все разительно отличалось в лучшую сторону! Поскольку клиент заплатит только за результат — то есть смысл работать эффективно и качественно что бы к релизу не утонуть в багах.
Один вопрос меня постоянно смущал: если проект fixed-price и клиент платит за результат, а не за попа-часы то не логично ли что и команде то же нужно платить за результат — а не заставлять отсиживать рабочие часы за фиксированную ставку (как в большинстве ИТ компаний)?

Якщо команді платити за результат, то рейтинг компанії на ДОУ улітає в мінус нескінченність, а відгуки типу «кидають та не платять», «не ставляться як до людей», і т.п.

Есть два вопроса:
1. как мсье собирается оценивать каждого конкретного человека в команде и его вклад в работу?
2. «За результат» означает платить процент от прибыли, мсье к этому готов?

З тролінгом в інше місце.

По суті:
1. А приватний ключ вам не вислати?
2. Вже, але виключно за результат.

1. Ключ от квартиры, где деньги лежат?
2. Если уже, то молодец. Но это тогда получается набор фрилансеров

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

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

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

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

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

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

Daniel Pink в известной книге «драйв» подробно рассматривает различие между мотивацией рабочих и креативных работников (нас): www.ted.com/...ks/dan_pink_on_motivation

Поскольку расписаны только основные (крупные фичи), а контракт подписан и в нём есть куча неопределённостей, то всё равно кто-то должен будет заплатить. И никуда не денешься. Есть шанс уговорить клиента на 70-80% доп.требований при хороших отношениях и вовлечённости в проект, остальное платит исполнитель.

зачем платить за то, что делать не нужно?

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

При том, что я в целом совершенно согласен с предлагаемым подходом, мне кажется, что ты пытаешься представить fixed cost как T&M с предсказуемым концом денег (и, соответственно, времени, так как для IT T часто эквивалентно M), что вполне справедливо, адджайльно, никаких противоречий. Але є одне але.

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

Никакой клиент не потащит вас в суд «выбивать из вас деньги и штрафы», если в течение проекта они видели, куда и как расходовались их средства. И при этом они получили продукт, который, может и без бантиков, но делает то, что нужно.
Зато они на основании этого вполне могут не платить по счету, потому что формальные условия не выполнены, и акт приема-передачи не подписан. Я согласен, что счастливый заказчик не станет такого делать, однако же — бомба заложена. Иногда в компаниях наступает режим «не платить все, что можно не платить». Или решение об оплате принимает уже не тот менеджер, с которым ты работал, или там вообще кадровый состав сменился. Или отношения так и не удалось настроить, и к концу оба ищут способы прервать отношения с минимальными потерями. Счастье растворилось, контракт остался. Litera scripta manet.

И теперь уже тебе придется идти в суд. Но, как ты понимаешь, на самом деле никуда идти не придется, просто подписать убытки.

То есть, если косты — fixed, то надо хотя бы scope иметь flexible. Иначе управлять нечем, как тут скомпенсируешь неопределенности, только программистов сильнее прессовать, ну то есть стрелять в ногу. И именно отсутствие вот этого «пространства для маневра» и делает такой проект «обреченным». Кто-то с большой неопределенностью сделал план проекта, и теперь остается в него вписываться как получится. Любые дополнительные движения — за свой счет. Разве что ты включишь «делаем по минимуму, заметаем под ковер», что есть выстрел в другую ногу.

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

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

Спасибо, Кэп ;) Автор же предупреждает, что РМБОК его не убедил, а вы железный треугольник поминаете. Из практики и по ссылке подтверждено: мелкие проектики «для репутации на Апворке» как раз Каскадно отлично делаются. Для итеративности есть такой гибкий метод как RUP, но надо много курить матчасть ;) Скрам же рулит на средних проектах, у меня был РО, который 6 спринтов подряд увеличивал скоуп MVP... Но т.к. платил почасовку имело смысл не дурить клиента с 6-летним стажем, а deliver и прокачивать автотесты и интеграционные, т.к. мы не делали очередного «убийцу»-клон ченить успешного, а профессиональный продукт. Тут соль в фикседе и ответы с MoSCoW и прокачкой коммуникаций — оч. интересны, спасибо.

RUP слегка ни разу не гибкий. Ну разве что сооовсем чуть-чуть.

Статья хорошая как для введения, но не раскрыты два ключевых как по мне пункта.
1. Как бороться с не зависящими от вас изменениями. К примеру, у вас годовой проект и ключевой ключевой разработчик говорит эдак через пол года: мне предложили работу в другом месте, там больше денег и интересные мне технологии. Заказчику по барабану, что у вас кто то уволился — ему подавай продукт в срок. Как быть в этом случае
2. Стоит ли подписываться под продуктом, если сроки и бюджет впритык? У меня мнение такое, что это делать можно на начальных стадиях бизнеса, для получения хорошей репутации на апворке. Иначе пусть ищет индусов. Какое у вас мнение на этот счёт?

Мое IMHO по данным вопросам:
1. Алексей писал о том, что разработчики должны быть с разносторонним опытом, чтобы каждый мог подхватить кусок работы ушедшего товарища. Но это в идеальном мире. По сути, уход ключевого человека — это риск, и как и другими рисками этим фактором нужно управлять и уменьшать различными способами, кака вариант, добиваясь того, чтобы ничего не было завязано на одного человека с помощью шерингов знаний и т.д. Это в т.ч. задача Скрам Мастера, как по мне.
А что касается заказчика — тут, как мне кажется, выбор не велик. Если уж такая ситуация приключилась — выбраться без потерь у вас не выйдет. Или людей пресовать придется с риском потерять и остальных, либо обуждать с заказчиком дальнейший скоуп и приоритеты. Для этого есть такие инструменты, как матрица приоритетов (Must/Should/Could/Won’t have), согласно которой у вас в любом случае должен в конце релиза быть буфер на работу над Could Have фичами. Ну и в конечном итоге, если отношения с заказчиком нормальные, то он вполне нормально отнесется к такой ситуации, главное не пытаться его обманывать, сваливаясь в No trust/No Transparency сегмент матрицы доверия и разгребая потом последствия.
2. Если готовы к тому, чтобы работать в минус ради репутации — вперед. Т.к. в любом случае вы не успеете, ну либо как в известном меме построите домик из известного материала и палок, и будете стараться чинить быстрее, чем его будут ломать пользователи. Тут как-бы тоже дело такое, есть компании, модель которых построена на культуре овертаймов и порицания тех, кто работает только в пределах рабочего времени. В такой ситуации проект может даже прибыльным оказаться, но нужно быть готовым к тому, что текучка будет неимоверная.

Підписатись на коментарі