Офтоп
Лена Очкова

Письмо в редакцию: Забудьте об Agile и вспомните о людях

В редакцию vc.ru пришло письмо совладельца компании-разработчика AIC-Qsoft и сервиса amoCRM Михаила Токовинина, который критикует популярные методологии управления проектами и призывает обращать больше внимания на производительность сотрудников.

Если вы сильно увлечены Agile — скорее всего, вы дилетант. И дело не в том, что Agile или Scrum не работают, а в том, что никаких особых методологий де-факто не существует. Даже каноническое сравнение «водопада» и итерационного подхода — это, по сути, лишь спор о размере итерации.

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

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

Самое страшное, что все методологии опускают одну фундаментальную переменную — производительность специалиста.

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

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

Знаете эти веселые тесты на IQ, где сначала кажется, что задача нерешаема, но стоит посмотреть на нее под другим углом — и все получается? А теперь представьте, что уверенности в наличии решения нет. Вы легко потратите сотню часов, доказывая невыполнимость задачи, вместо того чтобы все-таки поискать. Попытайтесь поставить дедлайн или назначить премию за найденное решение — и все станет только хуже. Это отлично доказал в 1935 году тест Карла Данкера.

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

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

Цель и радость достижения цели мотивируют. Стабильная и равномерная нагрузка убивает.

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

Хотите вывести команду на пик ее возможностей? Дайте ей цель, победу и, самое главное, возможность отдохнуть. Рывок, победа, отдых; рывок, победа, отдых — вот цикл, при котором мы максимально эффективны.

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

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

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

Не стоит забывать, что мы работаем не с проектом, а с людьми.

0
46 комментариев
Написать комментарий...
Evgeny Medvedev

Михаил какой-то свой Agile критикует, честное слово.

Ответить
Развернуть ветку
Mikhail Podurets

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

Почему фанаты Agile цепляются за идею недельных или двухнедельных спринтов?

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

Уберите большие релизы, замените их маленькими спринтами

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

но абсолютно пренебрегают разработчиком.

"Люди и их взаимодействие важнее инструментов и процессов" - ценность Agile.

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

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

Ответить
Развернуть ветку
Andrew Nesterenko

Люто плюсую каждое слово! Хотел написать подобный коммент, но нет смысла. Тут все четко и по делу сказано

Ответить
Развернуть ветку
Max Yeremenko

Agile нет, но вы держитесь. Хорошей вам штурмовщины, здоровья.

Ответить
Развернуть ветку
Евгений Наумов

Всю статью можно заменить двумя предложениями.

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

Ответить
Развернуть ветку
Alexander Shibaev

Сначала люди думают, что Agile - это спринты, а потом его критикуют. Ну ок, чо.
Не нужно делать из Agile священную корову, вот и всё.

Ответить
Развернуть ветку
Sergey Smolnikov

Михаил просто глаза открыл.

Ответить
Развернуть ветку
Nikita Tanygin

вся суть методологий

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Андрей Захаров

"Даже каноническое сравнение «водопада» и итерационного подхода — это, по сути, лишь спор о размере итерации."

Ну наконец-то хоть кто-то сказал это вслух !

Ответить
Развернуть ветку
Виталий Смирнов

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

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
ObliQ Brutale

Михаил, если когда-нибудь познакомимся - буду долго жать руку за данную статью!

Ответить
Развернуть ветку
Pavel Guzhikov

Представляете, как усталость одолеет после достижения цели?

Ответить
Развернуть ветку
ObliQ Brutale

ОМГ, вы меня раскусили! Возьмите пирожок, знаете где

Ответить
Развернуть ветку
Artem Artjukov

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

Ответить
Развернуть ветку
Ershov Alexander

С точки зрения программиста
http://programming-motherfucker.com/

Ответить
Развернуть ветку
Dima Choock

Я прочел заметку Михаила и согласился, просто потому что весь мой более чем 20-ти летний опыт разработки тоже согласился :) Я прочел комментаторов-защитников scrum/agile и, знаете что, тоже согласился :)

Как так?

Уважаемые адепты scrum/agile написали про молоток с ножовкой, которые и под то заточены и под это и под конкретную руку настраиваются и по углу регулируются и вообще! учите матчасть и читайте инструкцию :)

Михаил написал про плотника. Для меня мысль о том, что бестолкового плотника каким молотком не вооружи он все равно все испортит, является самоочевидной. Так же как мысль, что стиль плотника (ок, здесь аналогия истончается, но еще не рвется :) связан с особенностями проекта/продукта.

Я управлял десятками команд, и, всегда, складывающийся стиль управления оказывался индивидуальным и каждой своей деталью и особенностью не помещался ни в какие стандарты. Я знал управленцев, которые делали все и всегда только "по фен-шуй" и проваливались раз за разом. И я знал управленца, который в каждом своем проекте выстраивал жесткую вертикаль подчинения себе лично и объявлял это скрамом на том основании, что каждое утро он устраивал митинг и раздавал всем по скайпу задания :) "Гибкость" он осуществлял самостоятельно, а исполнителей лишал инициативы и тем самым избавлялся от хаоса. И вы знаете что - все у него получалось :)

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

Ответить
Развернуть ветку
Leo Vl

У популярных гибких методологий (скрам, ХР) есть одна большая червоточина - то, что они расчитаны на кросс-функциональных специалистов в одной команде. И ориентированы прежде всего на кодинг, то есть они очень узкоспециализированы. Исключением можно назвать КАНБАН.

Ответить
Развернуть ветку
Mikhail Podurets

Вот что же вы все придумываете. Они расчитаны на кросс-функциональные команды. КОМАНДЫ!!!

Ответить
Развернуть ветку
Leo Vl

Это вы про НЕКСУС пишите. Читайте скрам-гайд, там все написано, есть на русском языке

Ответить
Развернуть ветку
Mikhail Podurets

Это я про скрам пишу. Покажите пожалуйста где в скрам-гайде написано про кросс-функционального члена команды.

Ответить
Развернуть ветку
Leo Vl

Так, каюсь. Перечитал, я не прав. Прошу простить

Ответить
Развернуть ветку
Mikhail Podurets

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

Ответить
Развернуть ветку
Leo Vl

скрам-гайд, страница 6, второй элемент списка

Ответить
Развернуть ветку
Mikhail Podurets

Scrum recognizes no sub-teams in the Development Team, regardless of particular domains
that need to be addressed like testing or business analysis; there are no exceptions to this
rule;

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

Ответить
Развернуть ветку
Leo Vl

Уже ответил выше, я ошибся, я не прав. Давайте жить дружно.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
VVilliam Blake

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

Ответить
Развернуть ветку
VVilliam Blake

не в методологиях, а в голове

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

Откуда такое утверждение? В "водопаде" например активно используются понятия "ресурсы" и "риск", кто мешает прикинуть производительность и заложить больше "ресурсов" - трудовых для реализации проекта?

Ответить
Развернуть ветку
Артем Митюшов

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

Ответить
Развернуть ветку
Mikhail Podurets

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

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Mikhail Podurets

Никакая методология не спасиет от идиотов

Ответить
Развернуть ветку
Валерий Кичкаев

чтобы это мир делал без идиотов

Ответить
Развернуть ветку
Александр Хорошилов

И никакая - от разработчиков, которые считают, что знают, что нужно клиенту, лучше самого клиента

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Mikhail Podurets

А откуда у вас такие данные про большинство случаев? Говорят, что мир меняется, поэтому и требования меняются..

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Dmitry Gusev

Agile -- это как раз и есть про людей, а не про процессы и методологии.

Прочитайте манифест Agile от 2001 года, в нем всего 9 строк текста на русском:

http://agilemanifesto.org/iso/ru/

Ответить
Развернуть ветку
Andrew Boiko

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

Ответить
Развернуть ветку
Хуршед Нурматов

Михаил - один из умнейших людей. Посмотрите его видео на Youtube

Ответить
Развернуть ветку
Алексей Сырчин

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

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Robert Schlegel

Совершенно верно замечено. Причем я бы дополнил- не просто дилетант, а ограниченный человек. не могущий понять и воспринять, что люди - разные, и мыслят по - разному. И задачи решают тоже разные.
У разработчиков и управленцев совершенно разные склады ума и образы мышления. Они обусловлены решаемыми ими задачами. Им трудно понять друг друга.
Управленец решает ЛИНЕЙНУЮ задачу. То есть есть исходная точка, есть цель, расстояние и направление до нее известно, ресурсы тоже. и главное- менеджер знает, что каждый шаг, каждое усилие однозначно ПРИБЛИЖАЕТ его к цели.
У разработчика так не получается, потому что его задачи- НЕЛИНЕЙНЫЕ. То есть сделав шаг, он не может однозначно сказать, приблизился ли он к цели, отошел вбок, или вообще пошел в обратную сторону. Образно- как поиск пути в лабиринте. Вроде дверь вот она, очевидна - но за ней тупик, и надо опять идти назад, и запомнить это место, чтобы не возвращаться. Систематизировать информацию, находить причинно-следственные связи, и так далее..
И просто смешно, когда собираются управленцы, которые умеют решать лишь линейные задачи - начинают выдумывать правила скоростного прохода лабиринтов :-) Прямой дрогой он от этого не станет, но послужит поводом, что по лабиринтам придется искать путь им самим.

Ответить
Развернуть ветку
Pavel Pokrovsky
Трудности возникают, когда задача не дробится на более мелкие.
Да, мы должны декомпозировать задачи.

А?

Ответить
Развернуть ветку
Julia Alekseyeva

1. В гибкой разработке учитывается непостоянство производительности разработчика. Сделать её постоянной увеличив итерацию? Сомневаюсь. Это непостоянство есть у любого разработчика даже в течение дня. Как перелагается его на пике производительности неделями держать? В том то и дело, что он не на станке работает.

2. Гибкая разработка - это ответ на реальность. А реальность такова, что через полгода у заказчика уже все может поменяться, поэтому он меняет требования и ждать многого уже ненужного несколько месяцев не готов. То есть я просто не вижу возможности работать иначе. У меня ни один клиент ничего полгода ждать не будет.

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

Ответить
Развернуть ветку
Valentine Budkin

Говорю Agile, подразумеваю Scrum, говорю Scrum - подозреваю Agile. Вот тут собственно и ошибка.
Agile как раз о людях, работающем продукте и готовности к изменениям. А Швабер с Сазерлендом, формализировавшие и популяризировавшие Scrum задолго до появления понятия "Agile Software Development" позиционировали его как лучший инструмент, чтобы быть "гибче чем водопад". Он стал эдаким компромиссом - формальный и анализируемый людьми для людей из корпораций и обещающий относительное спокойствие разработчикам на протяжении итерации.
Недавно я сумбурно рассказывал что у Scrum, не так уж много общего с Agile, а это две отдельные сущности. Если кому интересно, вот презентация - www.slideshare.net/vabue/scrum-is-not-agile

Ответить
Развернуть ветку
Alexandr Tokmakov

О наболевшем.

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

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

А вывод прост: разработчик - такой же "манагер" (простите за грубое слово), просто с, относительно новым функционалом, который до сих пор не систематизировали до уровня школ и университетов.
И у него тоже есть эффективность и ее замерять/увеличивать еще никто системно не умеет, кроме "человеческого ресурса" (лида/техдира).

Agile манифест и другие гибкие методологии тоже научились "наеб...ть" (простите).

Ответить
Развернуть ветку
Михаил Качалов

Боюсь представить что сотворит с мотивацией программистов Continuous Integration ))

Ответить
Развернуть ветку
Dmitry Simonov

Отличный разбор статьи Михаила:
http://www.cmsmagazine.ru/authors/zavertaylov/agile-those-mechanisms-and-trolls/

Ответить
Развернуть ветку
Читать все 46 комментариев
null