Комментарии 73
У меня на предыдущей работе план на будущий год ставили просто — объем выполненных работ или продаж + 20%. Соответственно расклад был простой — хорошую годовую премию получали раз в два года, как ни старайся — чистая математика.
Иная ситуация: детально прописанные атомарные требования (глубже, чем фичи или стори в бэклоге) дают возможность получить оценку трудозатрат. Но тогда у вас скоуп является определенным, вы режете его на куски и реализуете по итерациям, управляя изменениями, которые могут быть, но не так часты, например. Это не Agile и не Scrum как его инструмент, это IID (итеративный инкрементный ЖЦ, разновидностью которого, и является адаптивный ЖЦ) и там множество своих инструментов и для оценки и для управления.
Во-вторых, мне кажется вы немножко путаете возможное и необходимое, вот так категорично утверждая про невозможность.
Тут IMHO лучше вернуться и начать совсем с истоков. Манифест Agile действительно говорит что «мы ценим способность к изменению выше чем следование плану». Однако не надо забывать о том, что написано в самом конце манифеста: «мы все еще ценим вещи справа, мы просто ценим вещи слева больше».
Поэтому вопрос не может стоять ни о том, что оценка вообще не возможна, ни о том, что в Agile её не делают. Вопрос о том, сколько именно оценки приносит пользу. И в этом плане статья, которую вы комментируете, отражает дух и суть Agile manifesto лучше чем ваша вольная интерпретации Scrum Guide.
По моей фразе «после получения какой-то начальной картины по оценкам» разве верен ваш вывод о моей категоричности в утверждении невозможности получения оценок? Я писала не о невозможности, а о полезности, как раз-таки, этих оценок:) их применимости и рисков разрыва ожиданий.
И мне было бы интересно, что в моем комментарии вы считаете вольной интерпретацией скрам гайда?
Я ответил не по одной фразе, а как раз по всей логической цепочке где мелкие и не очень неточности подсказывают что есть некоторые проблемы с картиной мира Scrum. К сожалению, чтобы разобрать там все проблемы потребуются не одна и не две вдумчивых сессии, явно не формат комментария.
Но могу подсказать вопросы, которые помогут порыть глубже, для начала хотя бы в этом направлении:
1) Зачем бы DevTeam оставляли полную власть надо Sprint Backlog если «фиксированные оценки» могут существовать хотя бы даже и в рамках спринта? Что на самом деле фиксировано в inverted iron triangle?
2) Как у нас дела с обеспечением transparency если «начальная картина» заведомо создает ложные ожидания, которые обязательно надо «отработать»?
3) Действительно ли из всех значений в русском языке для uncertainty является неопределенность/неизвестность? Какой физический смысл может иметь вообще cone of uncertainty в этом случае? А если обратить внимание, что куда более часто это слово используется в смысле «неуверенность» и «переменчивость»? Могут ли в этом случае у него появиться границы? Возможна ли оценка, коммуникация и обеспечение прозрачности такой uncertainty?
4) Применим ли вообще эмпирический метод, который требует обоснованного формулирования гипотез, в ситуации когда у нас есть истинная «неизвестность»? Почему применяемые в scrum community модели хоть Stacey matrix, хоть Cynefin framework таки в область полной неизвестности относят совершенно не эмпрические Scrum и не Agile?
5) Ну и стоит ли смешивать в кучу разные причины по которым возникает неопредленность? А сколько их вообще? Как заказчик может влиять на наличие неопредленности? Как мы можем влиять на наличие неопредленности? Как конкретная пара мы-заказчик можем влиять на наличие неопредленности?
p.s. И в первоисточнике, кажется, было про слона:))
Если только не рыть дальше Михалковского «Как старик корову продавал». :-)) А я не рыл, лень. :-))
Тем не менее вы «выставили свой диагноз» о проблемах с картиной мира Scrum. Это как врачебный по фотографии:)
Не помогли даже мои пояснения.
А логическая цепочка такова: проблема долгосрочных планирования и фиксации параметров (несовместимы не равно невозможны) — полезность и адекватность оценок, если они все же требуются — выбор правильного подхода к управлению проекта (в том числе и с учетом степени неопределенности скоупа проекта на старте и возможности ее уменьшить) и работа с разрывом ожиданий и изменениями. Разрыв ожиданий не равно неверные ожидания. Это термин работы с рисками и бизнес-анализа.
И:) могу подсказать вопрос, который поможет порыть глубже, для начала хотя бы в этом направлении: что предлагает нам Agile из инструментов долгосрочного планирования?
В большом количестве случаев в рамках аутсорсинговых контрактов (например) или для ПО для собственных нужд (возможно банковского, например) когда возможно определить скоуп (нет исследований, проверки гипотез) оптимальным является выбор IID ЖЦ, а не гибкого, с предварительной фазой диагностики и фиксациями параметров проектного треугольника и в дальнейшем с процессами работы с планом и с изменениями и т.д. Это поможет снизить риски разрыва ожиданий. При этом ничто не мешает нам быть Agile в таких проектах в более широком смысле этого понятия.
Автор статьи и сам прекрасно понимает проблемы использования выбранного подхода. Я в таких случаях предлагаю «не натягивать сову на глобус», а посмотреть в сторону других инструментов и подходов.
Единственное, обращу еще раз ваше внимание на то, что вы исключаете из задачи коллектив, оставляя только саму задачу и делаете на основе этого вывод об оптимальности и применимости.
Подумайте над такой ситуацией. Мы имеем на руках ваш же собственный пример с эволюционировавшей системой. На руках только относительно лежащие в русле проекта доделки, команда излазила проект с верху до низу и имеет достаточную базу шаблонов и наработанную практику для оценки типовых задач в рамках системы. Интеративный процесс на грани полного сваливания в предиктивку отлично справляется с работой.
Теперь происходит одно простое событие. Уставшее от однообразной работы ядро команды сваливает в светлые дали на интересные проекты. Что произойдет прекрасным отстроенным итеративным циклом на проекте, на котором сложных задач нет, а гипотез проверять не надо?
Еще раз почеркну — я не спорю с вами о возможности или невозможности итеративного цикла. Есть каждой вещи место под солнцем©. Я всего лишь напоминаю что координат по которым мы выбираем процесс не одна — проект. И опять верну вас к Disciplined Agile — их там 8 (восемь!). Поэтому говорить ни о «оптимальном для большинства», ни уж тем более о «я манагер, я знаю»© лучше не надо.
Как раз наоборот, у вас прекрасное и легкое изложение вполне себе логичных вещей. «Аффтар, пеши исчо» прям просится в качестве комментария. :-)
Что здорово — это то что у вас вполне себе рабочий механизм для работы с неизбежной неопределенностью. Единственное, по сути он остается попыткой адаптации предиктивного подхода — scope зафиксирован, мы играем сроками и бюджетом. Это не плохо и не хорошо, это просто один из путей.
Все-таки для того, чтобы перейти к действительно Agile треугольник надо перевернуть — у нас зафиксирован бюджет и срок, а главный вопрос «какую наибольшую пользу можно принести в оставшееся время и за оставшиеся деньги».
Но тут надо, я так понимаю, тоже надо делать поправку, EBITDA и прочие FATCA звучат не зря, и банковская область тоже не зря. Некоторые задачи, особенно связанные с regulations таки надо превращать в предиктивные, слишком уж высоки риски (турма сидеть например) за non-compliance. Просто в этом случае применение PMBOK может оказаться полезнее попытки нанятуть Agile методы. Тем более что нормальная предиктивка никак не отрицает замечательных вещей, сказанных про accountability и проблем с культурой. Наоборот, вооружит тех самых людей полноценным инструментарием для вдумчивой оценки.
Т.е. PMBOK это предиктивка по-вашему? :)
6 редакция уже достаточно много в себя взяла чтобы считать её основой для добротного гибридного подхода. Но многие методы, скажем активное использование work breakdown structure таки основываются на гипотезе, что работу можно понять разложив её на части, и оценив каждую из них. Определние сложной системы прямо этому противоречит, и такой подход не оставляет места для эмержетного поведения системы которую мы оцениваем.
7 редакция обещают будет куда сильнее склоняться в сторону Agile, не зря в конце коцнов они последний год такие усилия по развитию и проталкиванию Disciplined Agile предпринимают. Но лучше мы будет рассуждать «о вкусе этих омаров»© когда их попробуем. :-)
Все-таки для того, чтобы перейти к действительно Agile треугольник надо перевернуть
Для того чтобы прийти к Agile нужно научиться бизнесу продавать этот самый Agile. Я пока не встречали ни одного бизнесмена, который бы спокойно принимал идею — «мы тут делаем, на за что не отвечаем, но раз в две недели получаем много денег». Были те, кто соглашался, но чтобы кто-то прямо говорил «во, так и надо» не видел ни разу.
Но, возможно, дело просто в том, что идея «мы тут делаем, на за что не отвечаем, но раз в две недели получаем много денег» скорее отражает распространенное заблуждение об Agile.
Когда в Agile говорят про доверие и про внутреннюю мотивацию — они говорят не о том, что все люди по волшебству agile вдруг становятся хорошими. Просто мир сам по себе уже жесткая штука. Не поработал — не получил денег. Не получил денег — нечего кушать. Эти факторы уже говорят о многом, и если вокруг людей будет ходить начальник и рассказывать им какие они плохие что не работают хорошо — он не объяснит этих истин лучше.
Я начальник, я пробовал, точно говорю — не помогает от слова совсем. :-)
О, кстати, спасибо за идею. «Agile не предоставляет кредит доверия» и «доказывать что заказчик может им доверять — первостепенная обязанность Agile команды» хорошая тема для статьи. На русском точно не видел.
И да, «стройте проекты вокруг мотивированных людей» совершенно не зря один из принципов Agile.
А вот людей, которым интересно получать каждые две недели очередную работоспособную версию продукта с улучшениями вместо того, чтобы год сидеть как иголках и думать «эти тоже не справятся или нет» — более чем достаточно.
Ну не знаю… Всегда один и тот же вопрос — сколько будет стоить вывести конкурентноспособный продукт на рынок? Если ответ на него — «мы не знаем, давайте делать пока он не проучится», то желание выделять деньги резко улетучивается.
О, кстати, спасибо за идею. «Agile не предоставляет кредит доверия» и «доказывать что заказчик может им доверять — первостепенная обязанность Agile команды» хорошая тема для статьи. На русском точно не видел.
Ну я об этом и говорю — продать бизнесу Agile == продать доверие к команде. Если я верю, что они приложат все усилия для достижения цели и они знают своё дело, то выдавая денег столько, сколько просят я инвестирую их максимально выгодно. Даже если проект в итоге провалится, я расходую средства эффективно. Проблема в том, что стоимость установления таких отношений слишком высока. Вы не можете устроить конкурс среди 10 команд и реально разобраться в каждой из них. В итоге ничего другого кроме монетарных методов контроля рисков нет, во всяком случае для аутсорс команд или фрилансеров.
При этом заказчики бывают разные. Я лично встречал тех кто уже не раз получали такую оценку и понимали что все равно гарантий завершения проекта ноль и готовы были отгружать ежемесячно деньги в обмен на регулярные релизы.
А доверие ты не продашь, заказчик видит вас впервые в жизни, с чего ему доверять команде?
Я, простите, оцениваю ситуацию как рук-ль со стороны, так сказать "бизнеса" (причем не IT): а в чем проблема, что каждый будет заниматься своей зоной ответственности, нести за нее ответственность (на уровне KPI) и таки да — в компании начнут с доверия сотрудникам.
Product генерит список фич (это его работа, ее маркетинговая часть), Project — связующее звено между бизнесом и программистами, который позволит и сроки не "накрутить" и загрузить команду невозможным, в результате происходит нормальная оценка в разрезе "ожидаемая прибыль/затраты на реализацию (в т.ч. временнЫе)" и всё работает.
Единственный рабочий способ давать нормальные оценки — научиться угадывать. Единственный способ научиться — сделать пару раз похожие задачи. Все. Там где люди год за годом пишут одно и то же с оценками более менее все хорошо. Во всех остальных местах — жопа.
Я вам волшебный способ подскажу — оценка сверху. И сразу все ваши пятые точки… эмм… исправляются.
Технически тривиальные действия вроде формошлёпства и дёргания стандартных сервисов пишутся быстро. Гарантирую для них оценку сверху «неделя» (под моим контролем, разумеется). Но как только выделяющий финансы видит неделю и переводит её во что-то вроде 50к, то сразу возникает понятное отторжение — за одну форму 50к?!!! Вот в этом и кроется реальная проблема.
По сути мир хочет не оценку сроков, а к ней ещё и собственное удовлетворение от понимания «да, я действительно согласен, дешевле этого я не куплю». Как только снимаем эту проблему — о чудо, сразу всё начинает работать и никаких проблем не возникает. Так что ваша «жопа», на самом деле не ваша, а тех, кто привык экономить на спичках.
Можно ещё про конкуренцию поразмышлять, но экономия на спичках здесь так же мало помогает.
ЗЫ. Удивляюсь, почему тривиальное желание сэкономить кто-то всё ещё всерьёз обсасывает с точки зрения «сроков разработки». Поработайте в каком-нибудь монополисте — быстро поймёте дзен.
То, что вы называете «тривиальное желание сэкономить» другие могли бы назвать «желанием эффективно тратить деньги».
Вы говорите больше о продаже оценки начальству и я с вами согласен — дело именно в том, что 50к да форму для кого-то кажется дорого. Я же говорил (в разделе с жопой) о том, что оценки хорошо (в смысле точно) делаются там, где прохожее что-то уже не раз делали.
Опять не так. Точность всегда плавает, даже если это обыденное формошлёпство. Всегда есть уникальность, которая заставляет сдвигать сроки, если не в момент оценки, то по факту неготовности в расчётный срок. А если бы уникальности не было, то и формы были бы не нужны, поскольку их все бы уже сделали.
Ну и про «непохожее». Точно та же ситуация, но наоборот. Всегда кто-то делал что-то похожее. Без исключений. Потому что никакой бизнес никогда не вкладывается в проект, который никто не делал (то есть непонятно, работоспособно ли оно вообще). Вложения в такие направления — чистые исследования и там нет привычных сроков и нет ожидаемой прибыли (в кратко и среднесрочной перспективе).
>> другие могли бы назвать «желанием эффективно тратить деньги».
Нет, снова повторюсь — обычная жадность. Помноженная на глупость.
Жадность обычно у больших контор. Вот возьмём гугловый ведроид. Оценка сверху на него — 15-20 человеколет. Умножаем на 200к$ в год (гугловая же з/п), получаем жалкие 3-4 миллиона. И это в ситуации, когда они на маркетинг своего ведра тратят на порядок больше. Но при этом напрягают разработчиков со сроками, пытаясь сэкономить на части затрат, которая гарантированно меньше 10% от общих вложений (в реальности даже процент не факт что есть, если исключить поддержку). На мой взгляд очевидный пример. Хотя да, можно списать на абсолютную тупость гугловых финансистов, но я бы списал именно на жадность. Правда жадность эта, своего рода, «вселенская». В смысле — все так делают. И если конкретный манагер так делать не будет — его уволят. Но в результате, получив микроскопическую экономию, все большие конторы всегда теряют качество. Но у остальных всё так же, поэтому им плевать. Поэтому предпочтение отдают именно жадности. Чистой и незамутнённой.
Ну и глупость — те, кто не знает броду, не суются в воду. Либо у них есть «план Б». Если не знаешь, сколько стоит решение, то либо не лезь, либо готовь подушку исходя из всё той же оценки сверху. Всё остальное — жадные и глупые буратины. Ну а вы их, почему-то, решили оправдывать. Подозреваю, что и вам нужен ликбез, который я этак коротенько и зачитал.
Ваша концепция жадности и тупости слабовата. Положим вы правы в части с тупостью. Тогда выходит, что повсеместно менеджеры неэффективно тратят миллиарды, потому что так принято, а CEO не в курсе и ситуация повторяется из компании в компанию? А акционеры многих (всех?) компаний также закрывают на это глаза?
Зп топовых инженеров гугла > 1 mln/год, аналогично в FB, Netflix, Apple, Amazon. 2/3 этой суммы это акции, но сути дела это не меняет. Сложность современного Android уже далеко не 20 ч/лет. На момент покупки — возможно, но потратить 2-3 года на разработку своей ОС Гугл не мог, они бы остались без рынка. А ещё есть риск провала проекта — как получилось у Nokia с его Symbian и Maemo, стоимость этой ошибки нам уже известна. Зная, что будущее компании на кону, что риски провала реальны, что времени совсем не осталось, что конкуренты уже сделали ОС и вовсю клепают всякие push notifications, App Store, iCloud и т.п. — сколько вы готовы заплатить за решение проблемы?
Я про жадность акцентировал. А глупость в масштабах миллиардных дел состоит в действиях «как все». Ну и в неидеальности человека.
>> А акционеры многих (всех?) компаний также закрывают на это глаза?
Конечно. Они же первыми жадность вокруг себя внедряют. Стандартная картина — где мой ROI? И ему дают то, что он просит.
>> Сложность современного Android уже далеко не 20 ч/лет. На момент покупки — возможно
Именно современного я и оценивал. На момент попкупки трудоёмкость была не более 5 лет.
Собственно вы поинтересуйтесь тем, что эта ось из себя представляет. Внутри это обычный линукс. Компиляция под набор инструкций ARM занимает ну самое большее день трудозатрат. Далее нужны драйвера. Гуглы их написали всего лишь для одного пилотного устройства, то есть там трудозатраты опять небольшие (ну пусть пол-года). Затем поверх линуха прикрутили недо-микро-JVM, то есть по функционалу и доступным библиотекам даже рядом не стоящую с JVM от Sun на тот же год. Этакую микро-машинку можно сваять максимум за год. И над этим безобразием (а как беэ этого?) был водружён самописный велосипед для реализации UI. Уж лучше бы они его не выдумывали. Потому что эта пакость и сегодня цветёт и пахнет, и с нею приходится бороться куче разработчиков. Погуглите, например, single activity app, просто что бы понять, что нормальные люди давно на помойку отнесли весь этот шлак. Но трудозатраты и на него были, поэтому добавляем ещё пол годика. Итого имеем 2 года оценки снизу и 5 лет сверху.
Далее лет 10 гуглы были не в состоянии закрыть бесконечное количество дыр в их ржавом ведре, ну и на эти дыры они героически тратили десятки миллионов баксов. Это тоже трудозатраты, но я их всё же не включаю в свои прикидки, ибо зачем повторять чужие глупости? Правда включать в прикидки надо ещё инфраструктуру для пользовательских развлечений, как например — браузер, набор игрушек, всякие калькуляторы, доступ в соц. сети и т.д. и тп (включая ихний play market). Вот в сумме и набежит 15-20 лет на приличную ось с набором софта для инфраструктуры.
>> потратить 2-3 года на разработку своей ОС Гугл не мог, они бы остались без рынка
Я вам по секрету скажу — айфон задумали в 2004-м, вышел он на рынок в 2007-м. И ничего, не остался без рынка за три года.
>> А ещё есть риск провала проекта — как получилось у Nokia с его Symbian и Maemo, стоимость этой ошибки нам уже известна.
Я что-то зпамятовал — подскажете стоимость? А то вижу массу контор, которые тоже делали смартфоны, но не стали такими успешными, как двое лидеров. И ничего, все они живы. Для примера вспоминаю (с тёплыми чувствами) соньку — её sony-ericsson p910i просто супер. И появился как раз где-то в 2004-м, ну может пятом. Реально куча положительных впечатлений. Софт адаптирован к наличным в железяке запчастям, всё работало реально очень удобно. Но они забросили направление, перешли на дырявое ведро. Но не умерли, до сих пор живут. И так же было со многими другими.
>> Зная, что будущее компании на кону, что риски провала реальны, что времени совсем не осталось, что конкуренты уже сделали ОС и вовсю клепают всякие push notifications, App Store, iCloud и т.п. — сколько вы готовы заплатить за решение проблемы?
Ой, не надо столько эмоций. Будущее на кону только у тех, у кого в голове каша вместо мозгов. Я повторюсь — неудачные продукты были у всех без исключения. Для толстых контор это не просто несмертельно, но это их повседневная жизнь. Это нормально. И никаких эмоций.
Ну а в плане «сколько вы готовы заплатить за решение проблемы?», были бы у меня деньги, я бы без особых сомнений вложил те самые 3-4 ляма в софт и ещё 30-40 в рекламу и продвижение на чужих платформах. Но если бы я понял, что вложив ещё 3-4 ляма, можно получить существенно лучшее качество — я бы вложил ещё. А вот гуглы и прочие конторы типа «это дорого» предпочитают банально паразитировать на монопольном положении (по сути случайно приобретённом). Поэтому я и говорю про уверенность при вложении денег — гуглы неконкурентоспособны с их реально ржавым ведром (и это спустя почти 15 лет после его выхода). То есть 2-3-4 года ничего не решат, когда монстры не способны к серьёзным улучшениям и за 15 лет.
Ну и за одно — корпорациями правят далеко не гении. Просто подумайте об этом, и сразу многое в ваших представлениях изменится. Не надо обожествлять вполне земных людей и их продукты в виде толстых контор с ленивыми сотрудниками.
Хотя вспомнил, что вы вроде фрилансер, наверное поэтому вам сложно отойти от проблем заказчика, который очень тесно с вами взаимодействует. Но ещё раз — если заказчик не имеет плана Б на случай, когда не получится так дёшево, как ему бы хотелось, то значит ему не место в бизнесе. Потому что иначе это чистой воды рулетка — повезёт или нет. А рулетка — это не бизнес.
Я что-то зпамятовал — подскажете стоимость?
Падение капитализации в 10 раз, потеря одного из основных рынков, сокращение персонала, уменьшение выручки.
Я повторюсь — неудачные продукты были у всех без исключения. Для толстых контор это не просто несмертельно, но это их повседневная жизнь.
Когда ситуация типа «Apple захватывает ваш основной рынок» или «Tesla получает ключевое технологическое преимущество» то смертельно. В других ситуациях — норм.
Ну а в плане «сколько вы готовы заплатить за решение проблемы?»
Вы не поняли в чем проблема :) На одной чаше весов «повысить шансы зайти в рынок размером в 0.5 триллиона», а с другой стороны «сэкономить 10 млн. долларов».
Ну и за одно — корпорациями правят далеко не гении.
Обычные люди управляют, не глупее меня и вас. И они ситуацию понимают не хуже меня или вас. А с учетом того, что информации у них больше, и свою жизнь они потратили не на алгоритмы, а на управление, то скорее всего они больше, в среднем, знают и, в среднем, принимают более рациональные решения чем вы или я.
Вообще говоря, вообще комментарии больше на теорию заговора похожи. Выходит вы лучше всех знаете как надо, но почему то все глупые, как вы хотите не делают. Удачи с таким подходом, жизнь все по местам расставит.
У вас описан идеальный мир, которые не допускает существования ситуации, в которой как бы они все не были идеальны и тщательны, а на деле:
— Это чертовски трудно для stakeholder взять и точно рассказать что ему надо.
— Что неизбежная проблема что человек слышит одно, понимает другое, а пишет совсем третье. В глухой телефон все еще в детстве играли. А у нас в цепочке их несколько stakeholder -> product owner -> project manager -> developers.
Доверие — доверием, а понимание ествественных ограничений — само по себе.
В Agile они обошли проблему того, что нету нормальных объективных критериев оценки работы, скажем, для product, очень просто, сразу задекларировав в 12 принципах:
— Через работоспособный софт как главное мерило прогресса
— Через частую поставку (а значит частые измерение)
Т.е. не стали бороться с неизбежным, а просто сказали — ну раз нельзя проверить требования (или любой другой этап) — так давайте как можно раньше и чаще проверять их готовым софтом. Вот и вся хитрость.
Собственно идея даже не айтишная. Все ж началось с Тойоты и их Toyota Product System, когда они издержки связанные с тем, что не понятно «что, когда и сколько купят», начали пытаться побороть. Отсюда пошел вытягивающий процесс, а от него потянулось все остальное.
Я все же являюсь адептом парадигмы, что нет неизмеримых вещей: есть либо плохие измерители, либо мерила. Обычно второе, следующее из первого.
IT- индустрия не уникальна в этом контексте. Эффективность вполне, извиняюсь, эффективно меряется в производстве, космической промышленности и даже в такой мегасложной с операц. т.зрения штуке как аэропорт. Поэтому затруднения в налаживании работы цепочки из 3 звеньев я относил и всегда буду относить исключительно к непрофессионализму отвечающего за эту цепочку.
IT — не уникально, но оно и не подобно ничему из вами перечисленного. Сравнение как водителя автобуса и таксиста. У одного набор каких бы ни было сложных, но стандартизованных и повторяемых операций, у второго — каждый раз новый клиент с новыми запросами и новыми критериями субъективной оценки. Может быть конечно толпы сторонников вашей парадигмы и бродят по просторам экономики, но даже для такой простой области как такси почему-то основными метриками остаются удержание клиентов и выручка, а искуственные KPI.
IT — не массовое производство. IT — это НИОКР, если вы сторонник производственных парадигм. И даже в космической области есть большая разница между запуском отработанной конструкции и разработкой новой.
Поэтому ситуация не бинарна, как вы пытаетесь её изобразить. Есть измерения, есть измерители, а есть люди которые пытаются померить линейкой темпиратуру.
Нежелание слушать певцов от Agile понятно, но при такой приверженности к вашей парадигме — я бы засунулся в вопрос нормирования НИОКР. Там достаточно много интересных открытий может ожидать, в первую очередь связанных с понятием времени жизни нормативов и от чего они зависят. Я просто с этой темой еще с советских времен знаком. :-)
Самый большой самолет A380 — это 4 миллиона частей. Стандартизованных, между прочим. Всегда одних и тех же, и в том же месте, и с той же целью в каждом экземпляре самолета. 4 миллиона отдельных частей — это средненький проект сам по себе. Я управлял проектами размером 40-100 миллионов cloс, и беда в том что каждый из них был уникален. Ни в одном не было тех же самых частей с той же самой целью в том же самом месте. И если вы хотите притянуть сюда нормирование из массового производства, например, с конвеера, добавьте в вашу парадигму конвеер на котором сначала собирают ВАЗ 2101, а следом за ним сразу же Toyota Land Cruiser. А потом захотели ну такой, с крылышками… А, да, самолет называется. Ну типа Cessna 172. А че, мотор у обоих есть. Колеса есть. Приборы есть. Че тут сложного на том же конвеере собрать и те же метрики использовать. :-) Вы ж инженеры.
Вы пытаетесь бороться со мной количеством слов, это непродуктивно — лучше просто по существу. Меняется всё и вся и любой бизнес и как раз искусство — подстраиваться под изменения: любая выигрышная вдолгую стратегия — не статична. Поэтому повторю еще раз: IT не исключение. Мне видится, что в силу молодости этой индустрии в ней велико желание акторов (на всех уровнях) изобрести колесо, в то время как проще было бы перенять все хорошее (как тот же Lean от Тойоты) и тратить энергию на развитие.
А вот если вы знаете конкретный пример хотя бы одного НИОКР сложности хотя бы уровня автомобиля, который бы был оценен заранее, проверялся только KPI, и дошел до производственного образца в заранее предсказанный срок, уложившись в бюджет, без экспериментов и прототипирования — я с удовольствием первым побегу приникать к глубинам мудрости предиктивных манагеров от R&D. :-)
Вы уводили разговор в сторону с самого начала, но теперь начали просто хамить и переходить на личности. "Предиктивные манагеры" ставят для меня точку в этой дискуссии.
Помимо предиктивного и гибкого ЖЦ, есть еще итеративные инкрементные (PMBOK версии 6).
Главная ошибка в
непонимании отличия
проектов с итеративной моделью жизненного цикла (с инкрементным наращиванием функционала продукта или без него), реализуемых по схеме фиксаций проектных характеристик и, чаще всего, ориентированных на управление фиксированными характеристиками проекта,
от
проектов с адаптивной (гибкой, Agile) моделью жизненного цикла (которая в свою очередь является разновидностью вышеназванной итеративной инкрементной модели жизненного цикла), ориентированных всегда на управление изменениями.
Разница в том, что в IID можно сформулировать требования (разработать чертеж боинга), сделать план на N итераций (не на весь проект как в предиктивном ЖЦ (waterfall)), а гибкие ЖЦ дают больше инструментов, когда этого сделать невозможно по причине неопределённости скоупа.
Еще пример с известным сервисом пассажироперевозок. Каков подход к управлению на старте его разработки (мой ответ: гибкий)? А сейчас (мой ответ: IID+Agile)? Почему? Подсказка: с позиции возможности определить функционал и в целом целесообразность вложений в такой продукт. Более того сейчас не требуется проверка гипотез в принципе о возможности существования такого сервиса, она скорее потребуется в отношении каких-то конкурентноспособных фич, если на текущий момент разработка такой реплики вообще целесообразна:) Но это покажет другой анализ. Здесь пример для ЖЦ.
Если оставаться на примере с НИОКР — есть большая разница между задачами НИОКР «улучшить одну характеристику существующего образца» и «создать принципиально новый образец». Это разница давно и хорошо известна, и тот же ГОСТ еще 89-го года на нормирование задач НИОКР не зря вводил понятие применимости нормирования, жизненного цикла и срока жизни нормативов.
Вы, кстати, еще раз — идете по пути AUP :-). Все очень знакомые посылки. Вы можете срезать путь сразу перепрыгнув в Disciplined Agile, там это рассмотрено.
Если говорить о «главной ошибке» — то она как раз кроется в идее что выбор жизненного цикла может зависеть от нас. Это не так. Выбор зависит от условий задачи, и, кстати, как раз процесс эволюции жизненного цикла в Disciplined Agile хорошо прописан. Забавно что вы в приниципе в конце как раз пример эволюции процесса и приводите.
Даже если взять водопад — он не хорош и не плох. На проектах, которые могут быть сделаны водопадом — водопад даст результат быстрее и дешевле. Просто потому что куча времени на промежуточные релизы и итеративность не тратятся впустую. Попробуйте чуть-чуть сдвинуть фокус с нюансов организации жизненного цикла (я подозреваю что все их знают и понимают достаточно хорошо) в сферу вопроса «а что именно делает конкретный процесс применимым или неприменимым для конкретного проекта» (и как правило с этим знанием сложнее, вон «не самый плохой заказчик»(tm) со слепой верой во всеприменимость KPI хороший пример).
И ваша, и «не самого плохого заказчика» возможная проблема в рассуждениях как раз в том, что вы как-то получается ставите метод на первое место и пытаетесь обобщить опыт, пригодный для частного случая — как опыт пригодный всегда и везде.
А на первое место надо ставить ставить все-таки две вещи — конкретную задачу и конкретный коллектив который её решает. И искать жизненный цикл и способы которые дадут наиболее экономически эффективное (не «самое дешевое», оценка экономической эффективности немного шире) решение для поставленной проблемы в конкретных условиях. :-)
Для меня твой комментарий самый ценный честно говоря, потому что все остальные в ИТ варятся и для них моя статья мало чего нового дает. А вот вопросы со стороны очень ценные.
Чтобы не затопить тебя текстом вброшу простую мысль — за 15 лет работы в ИТ мне ни разу не встречались работающие KPI для ИТ.
Более того, мне даже ни разу не встречались KPI которые бы не приносили компании конкретный вред.
Более того, специальная литература не упоминала работающие KPI, зато с азартом разбирала как ИТшные KPI рушили компании.
Более того, на обучении менеджменту на МВА под эту проблему с KPI было подведено теоретическое обоснование.
Я так понимаю из контекста, посыл — "нет работаюших KPI в IT"?
Я рассуждаю так: KPI (в любой индустрии) это система оценки эффективности сотрудника, работающая на том уровне точности, который позволяет компании осуществлять планирование своего развития и воплощение в жизнь принятой стратегии.
Если вы согласны с вышеуказанной формулировкой (она исключительно моя, основанная на опыте, не из книг, при всем к ним, разумеется, уважении), то напишите пару аргументов в пользу утверждения почему именно в IT KPI работать не могут.
То, что люди начинают «подстраиваться» под KPI — это хорошо и так и должно быть, для этого KPI и создаются. То, что вы видите проблемой — не проблема KPI как такового (это просто инструмент, как нож — можно резать колбасу, а можно под ребра), а проблема неправильно *выстроенных* KPI.
На самом деле это довольно сложная штука, потому что построить систему KPI, в которых они будут работать органично между различными бизнес-юнитами — достаточно большое искусство (которым, к слову, мало кто владеет), но выстроив эту систему, понимаешь, что она начинает работать.
Если хотите — можем вместе построить такую систему. Создавайте виртуальную команду из 3 функций (чтобы не закапываться на неделю с этим упражнением) и составим для нее KPI. Ну если я буду понимать эти профессии, конечно. Ну, например, Product Manager, Project Manager и программист. Или Data Scientist и Data Engineer (2 функции). Это я привел в пример тех, чью работу я *понимаю*.
то напишите пару аргументов в пользу утверждения почему именно в IT KPI работать не могут.
Они мало где могут работать вообще. Ибо как только работу начинают оценивать по KPI — работа начинает оптимизироваться исполнителем для увеличения оного KPI.
Пока это что-то вроде "больше деталей сделал — выше показатель" — это ещё более-менее… но потом кто-то вдвое увеличивает скорость рассверливания вала, получает удвоение производства, звание передовика, премия, а в результате самолёты начинают падать ибо в результате нарушены напряжения в оном валу. Середина прошлого века.
В айти… а что конкретно в айти есть из рабочих KPI?
Количество поставленных фич? Начинаем рубить всё на мельчайшийшие фичи.
Количество строк кода? "Индусский код" приветливо машет спагетти.
Количество найденых багов? Начинается торг с QA что багом считать, а что занести в старый или сообщить неофициально устно.
Количество исправленных багов? Снова торг с QA.
См. мой комментарий Kanut79 выше. Предлагаемые вами KPI, во-первых, исключительно количественные, во-вторых, однобокие в разрезе "больше — лучше". Отсюда и сложность в решении задачи.
Что характерно — примера "правильных KPI" в ответ так не приведено. "Они есть, верьте на слово; а те, что в реальности то и дело пытаются использовать — они какие-то однобокие и количественные, неправильные".
И видится мне, что таковой KPI может быть одним-единственным — насколько фирма приносит больше или меньше денег. Вся, в совокупности.
Нет, ребятки, так это не работает. Это *вам* надо, а не мне. У меня с составлением KPI для кросс-функциональных команд проблем нет. Если вы управленцы, то должны знать, что мы учимся всю жизнь и это прекрасно. А если вы исполнители, тогда не забивайте себе голову составлением KPI — это не входит в ваши задачи.
Нет, ребятки, так это не работает. Это вам надо, а не мне.
Увы, но именно Вы утверждаете что "есть правильные KPI, а то что Вы их не знаете — так плохо думали и не туда смотрели" — Вам это, наличие таких KPI для разработки, и доказывать.
Самый близкое к ИТ сравнение — это наука. Когда есть целая лаборатория узких специалистов и они ищут лекарство от рака. Людям из других индустрий сложно понять что подход «у вас два года чтобы найти лекарство от рака» не работает. А работает подход когда вы оставляете их в покое и ждете пока они сделают свою работу.
Lelant0s, прости, но я не буду теоретизировать и совместно искать KPI для разработчиков. В прошлый раз когда я разгромил при устройстве на работу действующую систему KPI компании — работу я так и не получил, так что у меня стойкая идиосинкразия на дискуссии на эту тему.
Человек буквально прямым текстом просил привести аргументы "почему KPI не работают" — ему привели. Ответ — "это неправильные KPI, но есть правильные".
И последовавший логичный конкретный вопрос "какие для разработки есть примеры работающих KPI?" — это не "набросились". Как и реакция на "они есть, сами ищите" — потому что ну вдруг и правда есть примеры и можно на них посмотреть и вдохновиться?
С заказчиком же дело другое. Хочет KPI — получит работу по KPI. Или кто-то другой её ему обеспечит, если KPI неадекватны. А тут не заказчик, а собеседник. С ним — дискуссия, аргументы, анализ, выводы.
Оценка — это ответственность всей команды, есть хороший принцип «ты оценил — ты и делай», который защищает команду от оценок, взятых с потолка.
Групповой ответственности не существует. Бывает только групповая безответственность. Да и сам принцип — такой себе. Ибо есть ненулевая вероятность выползания за дедлайн и тут начинается стандартная игра "ты обещал сделать к этому сроку, кранчи как хочешь, но чтобы к нему было готово", в результате которой страдает прежде всего сам продукт. О, привет, Киберпанк.
И сторипоинты с велосити тут не особо спасают, ибо в каждой задаче свои сложнопрогнозируемые приколы. Бывает простая задача затягивается на несколько спринтов, а бывает сложная реализуется за пару минут прикручиванием правильной либы.
Вот именно, что "как целое". Накосячил один, а отдуваются все. Или большинством принимаются неправильные решения, ибо оно не компетентно, а те, что компетентны — в меньшинстве.
В скраме то же самое формулируется как "вы же взяли это в спринт, но не сделали, атата".
А где это по другому?
Очевидно там, где у каждого своя зона ответственности.
То есть если люди не могут нормально вместе работать, то значит им пожалуй и не надо вместе работать.
Ну да, так команда теряет экспертов в чём либо, и оставляет лишь посредственностей о всём.
100% не скрам.
100% скрама в природе и не существует. Только на тренингах у кучей.
Всецело разделяю вашу точку зрения по поводу того, что ответственность должна быть *индивидуальной*, а принцип «ты оценил, ты и делай» — верный симптом болезни под названием «патернализм» (в простонародье — перекладывание ответственности), которая — по историческим причинам — эпидемией бушует на всем постсоветском пространстве. До сих пор.
Считаю важным поддерживать единомышленников. :-)
А иначе получается, что «к пуговицам претензии есть?» — то есть индивидуально все молодцы, а продукт не работает.
Если от каждого ждут результат, значит его можно замерять, а значит — выстроить KPI. Ничем IT не отличается от других индустрий в этом контексте. А групповая ответственность пилота и диспетчера будет повыше, однако ж и у них есть KPI.
я в этой индустрии уже 15 лет, но не могу сформулировать результат работы программиста. хороший код? а какой код хороший? как в определении верховного суда США — я узнаю порнографию если ее увижу?
хороший продукт? а какой продукт хороший? говорят что прибыльный, но при чем тут команда разработки? тут сейлзы и маркетинг бал правят.
Возвращаясь к вашим вопросам. Опять же, если готовы к дискуссии, то готов и я. Только давайте поэтапно и последовательно: какой продукт деятельности мы хотим получить от нашего программиста? Это на самом деле ключевой и не такой простой вопрос, как кажется на первый взгляд. Более того, ответ не может быть сформулирован одним словом. Предложением — может.
Какая ваша версия?
ему было как раз предложено вместе подумать, его это не устроило
Вот незадача, я как раз подумал. В ответ было "это просто неправильные KPI". И на этом "совместное" думанье закончилось — с Вашей стороны примеров правильных так и не последовало. Хотя прямой вопрос, к Вам обращённый, был. Какая же дискуссия, если одна из сторон говорит "неправильно думаешь, а как правильно — сами ищите"?
Тогда у вас проблема не в том что у вас аджайл/скрам плохо работают, а в том что у вас на самом деле просто не аджайл/скрам.
По этой же логике "если вотерфол для вас не сработал — значит, это вы неправильный вотерфол сделали".
Эта удобная(чуть что не так — "это эджайл неправильный") и популярная позиция противоречит эджайлу. Ибо тот прямым текстом говорит "дорабатывать эджайл по месту", а не "сделать ровно так и так". Следовательно, нет "правильного эджайла" — по самому же эджайла.
И, в целом, то, что эджайл не сработал — ещё недостаточное основание говорить что он был неправильным.
У реальных разработчиков одного уровня и с одной зарплатой производительность может отличаться на порядок
Она ещё и внутри одного и того же разработчика меняется со временем, погодой, новой книгой/игрой и эмоциональными реакциями на окружающий мир.
P.S. Вспомнилось ещё, из читанного в Software Estimation: Demistifying the Black Art, что первая ошибка оценок — это выдача оценки в виде срока из одной точки(даты). Такая оценка всегда оказывается оптимистичной, и при оценке из промежутка("где-то между от даты и до даты") она становится нижней границей.
Казалось бы — одно поле, тьфу! А трудозатрат куча.
Освободится время у разработчиков, повысится их настроение(большинство любят кодить, а не отвечать на тупые вопросы уровня: когда рак на горе свистнет).
Ах ну да менеджерам придется отменить все их мимтинги и им совсем будет нечем заниматься, некому красивые графики рисовать)))
О проблемах нормальной оценки фич и как их решить