Лого vc.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0

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

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

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

0

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

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

0

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;

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

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

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

0

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

0

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

0

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

0

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

0

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

0

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

0

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

0

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

1) заказчик м*дак и меняет требования до момента плановой готовости определенной итерации
2) исполнитель м*дак и сорвал сроки итерации

"Мир меняется" - не оправдание, т.к. переносит ответственность на третью сторону. На эти случаи есть форс-мажоры. Но "мир изменился" к ним обычно не относится, в отличие от ЧП и катастроф. Поэтому две ситуации - либо 1 и это ответственность заказчика, либо 2 и это ответственность исполнителя.

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

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

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

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

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

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

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

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

agilemanifesto.org/iso/ru/

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

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

0

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

А?

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

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

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

0

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

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

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

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

0

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

0

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

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

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

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

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

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

Как так?

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

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

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

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

0

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

Прямой эфир
Компания отказалась от email
в пользу общения при помощи мемов
Подписаться на push-уведомления