Бесконечная итерация: менеджеры из Ада

EscherMoebius

Agile, команда, менеджер

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

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

UPD: Я рассматриваю здесь ситуацию, в которой присутствуют проблемы с менеджментом и управлением. Как мне подсказали, из статьи выходит так, что во всем виноват менеджер; это не так. Просто именно тут я пишу о тех проблемах, о которых не видел упоминаний нигде более. Естественно, могут быть и другие ситуации, другие проблемы, но их я опишу как-нибудь в другой раз.

Thailand-2011-July-5-Giant-Buddha-with-Cobras-at-Sala-Kaew-Ku

Симптомы менеджера из Ада

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

  • Сроки ставятся вашим менеджером по только одному ему ведомым правилам;
  • Менеджер не хочет создавать новые итерации, придумывая разнообразные причины, почему это не нужно, все работают в одной и той же итерации месяц-два-три-год;
  • Команда, в которой вы работаете, постоянно срывает поставленные менеджером сроки, а релиз (или завершение итерации) отодвигается все дальше и дальше;
  • Каждый раз при срыве сроков находятся какие-то очень важные и неизбежные причины, которые полностью снимают ответственность со всех, кто работает в команде;
  • В сроки релиза входят задачи, названия которых вам ничего не говорят и вы понятия не имеете, что это вообще такое;
  • В список задач ближайшего релиза постоянно добавляются новые и, чем дольше вы работаете над версией к этому релизу, тем больше появляется новых задач;
  • Менеджер считает, что он один может вытянуть весь проект и сделать работу лучше и качественнее любого из сотрудников. Если кто-то из них уволится, ничего страшного, он сам все сделает (о чем регулярно напоминается и команде, и заказчику);
  • Периодически приходит заказчик/инвестор/издатель и дает всем люлей делает всем выговор, обсуждает проблемы и требует новых сроков;
  • После беседы с заказчиком, менеджер возвращается в самый первый пункт этого списка и ставит новые сроки с мотивирующими (как он думает) словами «Мы должны успеть, иначе все!» (с большими выпученными глазами, которые (по его пониманию реальности) должны передать весь ужас ситуации и замотивировать всех до скончания времен);
  • Притом при всем, менеджер считает себя вправе приходить на работу в середине дня и не отчитываться о своей работе. Никто в команде не знает, чем занимается менеджер, потому что он подотчетен только руководителю/заказчику/инвестору и не обязан отчитываться перед командой.

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

          — Ну скажи, сколько надо времени?
          — Не знаю…
          — Ну примерно?
          — И примерно не знаю… Надо исследовать.
          — Ну хотя бы от скольки до скольки, в пределах? День, неделя, месяц?
          — Недели две, наверное…
          — Ок.

Знакомо? Уверен, что так. Далее менеджер идет, складывает полученные «оценки» сроков, умножает на два и ставит новый срок релиза. Ура! Цель поставлена, можно к ней двигаться, теперь все будет хорошо! Но нет, не будет. Срок опять провалится, опять будет цикл заказчик-люли-планирование-новая постановка сроков… и так бесконечно, пока либо все не развалится, либо пока проект не доползет до первой точки релиза (по прошествии времени, в несколько раз большем чем должно было быть затрачено). При таком подходе быть или не быть целиком и полностью зависит от терпения заказчика, которое никогда не бывает бесконечным. Примеры известны, например Parallax Art Studio, видеозапись разбора полетов в котором можно посмотреть тут  (кстати, терпения заказчиков хватило аж на семь лет и, если бы не Кранк, то может быть и лет на десять попил бы затянулся).

Подробно о том, почему адская итерация — это плохо и к чему она приводит, рассказано в следующих разделах.

 

Public Execution

Воздействие болезни на команду и на проект

1. Отсутствие видимого результата

Команда работает. Время релиза наступает. Релиза нет. Нет и бонусов, нет радости от запуска проекта, нет удовлетворения от творчества. Нельзя показать друзьям сделанное и сказать, «Смотри! Я делал!». Постепенно, через несколько проваленных релизов, вера в то, что проект будет сделан, иссякнет. Останется пессимизм и разочарование в деморализованной, демотивированной команде. Для команды нет ничего хуже, чем работать и не видеть результата (ну разве что еще и зарплату не получать). Во что превратится такая команда через год работы? В уставших, пофигистических овощей-фаталистов с потухшими глазами, напоминающих сушеные томаты.

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

Отсутствие веры в победу и результат — это уже наполовину проигрыш, наполовину поражение.

 

2. Замкнутый круг демотивации

Несмотря на пункт 1, вполне вероятно, что прогресс в разработке есть. Но, без завершенных этапов и промежуточных итогов, часто он никому не видим. Это как новорожденный ребенок, который растет: когда вы видите его каждый день, рост почти незаметен. Но если его не видеть две-три недели, то его изменения будут просто поразительными. С проектами то же самое, плавные и постепенные изменения незаметны. Притом каждый член команды знает, что он делает свою работу (худо бедно, в зависимости от того, сколько веры и энтузиазма у него осталось), но результата работы других он не видит. Или видит только небольшую часть того, что делают другие, в основном художники. Вполне понятно, что у сотрудников возникают мысли: «почему работаю только я, а остальные занимаются непонятно чем?» и «если они ничего не делают, то почему я должен работать за всех, почему бы и мне не сходить на обед часа на два, или приезжать на работу к часу дня?»

Что происходит дальше: те, кому в голову приходят такие мысли, начинают хуже работать. Начинаются игры в рабочее время, чтение блогов, приход на работу в час дня и уход в семь вечера, обеденные прогулки по полтора-два часа. Что видят другие? Что один из команды вдруг перестал работать и забивает… и безответственно относится к своим обязанностям. О чем они подумают? Правильно, им  в голову придет та же мысль: «Если ему можно, то почему мне нельзя?». Эта зараза будет расползаться в команде, распространяться как плесень, заражая все больше и больше людей.

Что делает адский менеджер в таком случае? Варианта два:

  1. Он увольняет наиболее зараженных, заменяет их на свежих и еще не демотивированных сотрудников;
  2. Ничего не делает, потому что его устраивает такая ситуация (это обычно для варианта освоения зарплатных денег инвестора; реже — потому, что такому менеджеру удобно самому приходить на работу во второй половине дня и никто не будет задавать вопросов).

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

3. Увольнения и репрессии

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

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

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

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

 4. Раздувание бюджета

Рано или поздно к менеджеру приходят демотивированные сотрудники, увязшие по самую шею, у которых нет больше энергии на дальшнейшее движение. Они приходят с двумя словами: «Я увольняюсь». Иногда слов больше, но суть от этого не меняется. Что делает адский менеджер, понимая, что ему придется отчитываться перед заказчиком о причинах увольнения сотрудника? Он предлагает повышение зарплаты и, обычно, это работает. Я видел только одного человека, который ушел не смотря на предложенное повышение (речь вроде бы шла о 30-40 тысячах, что для нашего рынка вполне ощутимо).

Проходит время, и зарплаты сотрудников становятся выше, чем по рынку. И вот уже небольшая вроде бы команда пожирает ресурсы на сколько-то процентов больше, чем должна и чем выделено на разработку, вплоть до 50% (чаще это превышение на 20-25%, но бывают и удвоения/утроения).  Заказчику рассказывается, какой сложный рынок, какие в команде работают крутые профессионалы и что заменить их вообще нереально, нужно держать всеми силами, иначе конец света.

Счастлив ли заказчик, что бюджет разработки постепенно вырос до значения, некоторое он, вероятно, раньше не рассчитывал? Вряд ли. Может ли расширяться команда? Тоже сомнительно.

На этом этапе мы имеем:

  1. Непонятные и невнятные сроки, взятые менеджером с потолка;
  2. Уставшую, деморализованную команду, которая не верит в то, что делает;
  3. Задранные зарплаты, которые уже не поднять тогда, когда надо реально наградить/поощрить сотрудника;
  4. Ежемесячный бюджет, который уже превышает лимит и лишает команду возможности расширения или маневра;
  5. Недовольного заказчика/инвестора, который в любой момент может свернуть разработку;
  6. Вероятно, Франкеншейновский проект, состоящий из разрозненных кусков кода и функционала, создаваемый самыми разными сотрудниками, которые были неоднократно заменены;
  7. Разработку, тянущуюся в разы больше реально необходимого срока.

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

 

beautifulsexynurseart

Лекарство

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

1. Воспитание

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

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

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

2. Введение обязательной регулярной демонстрации

Это — ночной кошмар адских менеджеров, и, вероятно, самое эффективное средство их исправления (или выявления их сути и увольнение).

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

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

Что дает такая демонстрация команде? Команда видит, что она сделала. Что они сделали все вместе; что сделал за это время каждый из членов команды. Такая общая демонстрация разрушает демотивационный круг, сплачивает людей, мотивирует их на дальнейшую работу. Мотивирует тут сразу же много факторов: люди видят, что они сделали и как это работает; они могут гордиться/похвастаться результатом своей работы; они видят оценку своей работы зрителями, их реакцию; они видят, что другие тоже работают и что они сделали за это время; они видят, что другие работают эффективно и хотят соответствовать команде (или они видят, что человек провалил свои сроки и задачи и публично об этом рассказывает — и не хотят оказаться на его месте).

Самое же главное это то, что команда видит плоды своей работы. Может быть не совершенные, не финальные фичи, но — результат. Это завершение одного этапа и начало нового. Пройдена еще одна ступенька, есть движение. Все видят, что они движутся, и это мотивирует, выжигает плесень безделья и лени, заставляет хотеть продолжать работать. Кроме того, проведение обязательных демонстраций не оставляет адскому менеджеру иного выбора, как работать итеративно, завершать текущие итерации и создавать новые (а, вместе с тем, и планировать вместе с командой, ставить реальные сроки, основанные на опыте команды и совместном разбиении задач… но об этом лучше читать в литературе по аджайлу).

Как стимулировать проведение демонстрации? Сначала назначить регулярное время и место проведения демонстрации. Если она проводится не в срок, задерживается или не проводится вовсе, назначить штраф (менеджеру) за сорванную демонстрацию.

Резюмируя: демонстрация — это очень важно. Вполне вероятно, что для многих команд это вообще самое важное и самое эффективное, что может быть предпринято для повышения мотивации и продуктивности работы. Многие, работающие по «аджайлу», пропускают/игнорируют демонстрацию и, затем, пишут статьи о том, как аджайл не работает и не помогает, что все это чушь и пустая трата времени. Надеюсь, после моего объяснения, почему демонстрация необходима, таких писулек станет меньше.

3. Добавил задачу в текущую итерацию? Заплати!

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

Если менеджер невменяем и, проработав много лет, так и не может этого понять, то прекрасным лекарством будет введение прайса за добавление новых задач. Например, один день на задачу — 1000 рублей из его зарплаты (из его потому, что именно он, и только он, отвечает за планирование работ). Любой заказчик/инвестор может смотреть трекер и следить за тем, какие задачи когда и куда были добавлены. Если он видит, что была добавлена задача в текущую итерацию, или две, или десять, он спокойно вычитает соответствующую сумму из зарплаты менеджера. Определить, блокирующая ли это задача или неважная, легко можно во время демонстрации. Через пару итераций с оплаченными задачами у менеджера пропадет какое-либо желание добавлять что-то неважное в текущую итерацию. Может быть, даже рефлекс выработается, кто знает? Было бы здорово.

4. Общение команда-заказчик

Есть одна история, в которой руководитель бездельничал почти что год, рассказывая заказчику красивые истории о том, как все будет. За это время не было сделано почти ничего; притом, команда все знала и понимала, но бездействовала. Когда я спросил ребят, в чем дело и почему так, оказалось, что они боятся заказчика. Я организовал переговоры и этот псевдо-руководитель был очень быстро уволен. Но почти год работы оказался выброшен в мусорное ведро. Почему так произошло? По двум причинам:

  1. Команда считала, что ничего не может сделать. Команде руководитель рассказывал об общении с заказчиком, о том, что все хорошо, все довольны и так далее. Заказчику же этот псевдо-руководитель рассказывал, какая плохая команда, но как он все вытянет как все сделает, что уже вот-вот и релиз (в то время, как даже 1/20 кода не было);
  2. Заказчик, будучи непрофильным, никоим образом не мог проверить слова псевдо-руководителя и мог только ждать дня запуска (релиза). Причин для общения с командой и выявления реальной ситуации просто не было.

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

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

4. Не ссать бояться и не жалеть

Если понятно, что менеджер прибыл в компанию из ада, не бояться его уволить. Команда (если не совсем деградировала) за ним не последует просто потому, что наконец-то сможет нормально и продуктивно работать, без непрерывного и бесконечного потока новых задач. Никто не любит воевать с гидрами и все любят получать результат (или почти все). За отправку адского менеджера обратно в ад команда скажет спасибо.

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

5. Бебиситеть

Это лекарство доступно только заказчику. Заключается в том, чтобы лично проводить планирование и демонстрации. Работает, но требует времени заказчика и постоянства, а очень часто у заказчика бывают другие дела в это время. Если это происходит нерегулярно, в разное время, то это лекарство почти не работает. По-моему, пенальти за не проведенные вовремя мероприятия (планирование, демонстрация) гораздо эффективнее.

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

6. День свободы

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

 

 

meditation-work

Картинка взята отсюда

Резюме

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

Если говорить с адским менеджером и требовать от него изменений в его работе, то ни в коем случае не тет-а-тет. Это должно быть командное решение и общая инициатива, иначе вас просто очень быстро уволят. Соберите единомышленников и составьте список проблем (претензий), которые вы видите в работе менеджера. Если вас достаточное количество, то вы можете попробовать решить эту проблему непосредственно с ним самим (я не верю, что это может сработать, но вдруг? По крайней мере, ваша совесть будет чиста, когда вы пойдете к заказчику/руководству).

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

И в заключение. Даже если вы работаете не по аджайлу (кстати, с канбаном я тоже знаком и не считаю, что это повод отменять итерации/демонтсрации), если у вас аллергия на это слово, регулярные демонстрации вполне могут быть. Они не будут такими эффективными, как если бы работа шла по аджайлу, но они будут работать. По крайней мере, они помогут выявить проблему в менеджемнте, или в продуктивности команды. Я настоятельно рекомендую не пренебрегать промежуточными демонстрациями. Правильно проводимые, они на самом деле очень позитивны, воодушевляют и очень хорошо сплачивают команду, одновременно мотивируя ее и выжигая лень. Ведь самая главная проблема адских менеджеров не глупость, а лень и безответственность.

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

UPD: что почитать

Хорошая книга, которую перечитал несколько раз (впервые еще когда не было перевода). К счастью, перевод был сделан уже давно, так что рекомендую — Scrum и XP: Заметки с Передовой (это .pdf, можно читать прямо по ссылке). Всем, кто интересуется Аджайл-методологией, рекомендую. Читать интересно и полезно.



Мысли на тему “Бесконечная итерация: менеджеры из Ада” (17)

  1. EN on 19.08.2013 at 3:08 пп ответил:

    автор говорит какие-то правильные вещи, но в вопросах методологии немного потерян. agile — это различные подходы к итеративной разработке, в том числе Kanban, Scrum, JIT и т.д. (http://en.wikipedia.org/wiki/Agile_management)

    • Анти on 19.08.2013 at 3:13 пп ответил:

      Да, только вот в канбане нет итеративного подхода — весь канбан это одна сплошная итерация которая, как я уже написал, на мой взгляд не подходит для r&d проектов.
      Цитата из приведенной статьи в вики про аджайл, кстати: «There are also links to lean techniques, Kanban and Six Sigma». А вот тут мы читаем, что такое lean techniques: http://en.wikipedia.org/wiki/Lean_project_management

      Поясню мысль: Agile — это итеративная методология и многие другие — XP, kanban, scrum — заимствуют многое из аджайла, но называть их аджайлом крайне странно и некорректно на мой взгляд. И наоборот, итеративная разработка — это далеко не всегда аджайл.

      Так что не будем говорить, кто потерян и в каких вопросах 🙂

      • EN on 19.08.2013 at 5:15 пп ответил:

        Прошу прощения, но Вы заблуждаетесь сильно)

        Agile был рожден Генри Фордом, переосмыслен японцами в Toyota и лишь затем переложен в рамки других отраслей, в том числе IT.

        Канбан является непрерывным процессом, верно, однако в его рамках в зависимости от проектных обстоятельств существуют полноценные «итерации», которые могут быть MVP или просто Feature.

        Следует различать feature в канбане и user story (ticket, task, etc.) в скраме, который в абсолютной степени agile, т.к. имеет строгие sprints (они же итерации).

        Скрам старше и немного неповоротливее канбана, т.к. создает проблему своевременного определения bottle-neck, а также не трекает feature (а feature, как раз, есть полноценный результат необходимый команде для оценки собственных трудов).
        И то, что вы называете демонстрационной встречей также существует под определением ‘retrospective meetup’, на котором всей командой обсуждаются проведенные работы, определяются ошибки, а также способы их избежания в будущем)

        Настоятельно советую почитать книги на тему или хотя бы послушать кого-нибудь кому доверяете.) kanban и scrum — это в абсолютной степени agile методологии управления проектами, а сам термин или понятие agile не является методологией управления, это скорее идеалогия, в основе которой стоит итеративный подход.

        • Анти on 19.08.2013 at 5:29 пп ответил:

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

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

          • Анти, ты не умеешь готовить канбан 🙂

            • Анти on 20.08.2013 at 11:10 пп ответил:

              Холивоооор! :))

              Я думал на тему предыдущего коммента кстати. Мысль такая: если взять Мерседес, к нему приделать руль от Жигулей, колеса от Форда, пропеллер от Ми-8 и ракетный движок, то все это может быть будет очень круто работать. Но это не будет уже Мерседесом. Канбан в софте, с итерациями — это уже совсем не канбан, там от него только доска со стикерами и осталась, разве что 🙂

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

        • >Agile был рожден Генри Фордом, переосмыслен японцами в Toyota и лишь затем переложен в рамки других отраслей, в том числе IT.

          [Agile] В феврале 2001 в штате Юта США был выпущен «Манифест гибкой методологии разработки программного обеспечения». Он являлся альтернативой управляемым документацией, «тяжеловесным» практикам разработки программного обеспечения, таким как «метод водопада», являвшимся золотым стандартом разработки в то время.

          вот Kanban действительно пришёл из офлайна в айти, но 2006 году 🙂

          DZone recently got the chance to speak with David Anderson, who pioneered the use of Lean methodology in software development known as Kanban. In this exclusive interview, Anderson tells us how Kanban got its start and gained momentum. He also identifies the two main groups that have driven Kanban adoption.

          The first use of Kanban-like methods, Anderson says, was in the fall of 2004 with a Microsoft IT department. The following year, he published the results of his experiment. The first implementation of Kanban, with all the modern attributes, evolved out of work that Anderson did at Corbis, which started in September 2006. In May 2007 Anderson started talking publicly about his experiences in Kanban. Its rise in fame, he says, happened in just the last two years, and its adoption accelerated in 2009. The Yahoo group, kanbandev, has grown to over 1000 members. Anderson says, «If you follow the Kanban tag on twitter, you’ll realize that there can be as many as six to ten tweets per hour talking about Kanban, and about 90% of those are talking about it in a software development context.» There’s also a large number of blogs that talk about Kanban. «I’m just amazed at how well the adoption has been going.

          • Анти on 05.09.2013 at 11:00 пп ответил:

            Вообще в предпоследней статье я рассказал о спиральной, итеративной системе в ИТ. Она возникла в 1986 году. Я полагаю, аджайл в текущем его виде — это как раз логическое развитие спиральной итеративной системы Бима.

  2. EN on 19.08.2013 at 6:02 пп ответил:

    Нашествие канбановцев? Увольте. Я лишь проинформировал Вас о неточности в посте, а как относиться к этой информации — дело Ваше.

  3. Чета я не догнал, как тут коментить каменты, поэтому пишу тут.

    В нашем канбане есть итерации, но они реализуются в рамках фич. Т.е. фича проходит стадии (упрощенно — ГДД, арт, разработка, тестирование) и после этого идет в продакшен. Не знаю, понимаешь ли ты, что я имею ввиду.

    • Анти on 21.08.2013 at 11:23 дп ответил:

      Пытаюсь понять.

      Как вы определяете сроки и ресурсы, необходимые на фичу? Например, надо сделать машину (первую, еще функционала нет). Она состоит из арта (модельки), физики (поведения) и управления. У вас есть денежные ресурсы на 3 месяца — как вы в данном случае считаете, укладываетесь ли в срок, нужно ли делать фича кат или наоборот, есть ресурсы на то, чтобы что-то добавить?

      Про комменты комментов — у меня есть кнопочка под каждым «Ответить», у тебя нет?

  4. Pingback: Прототип - убийца IT-стартапов | Gamedis.ru

  5. Pingback: Разработка игр с точки зрения бизнеса | Gamedis.ru

  6. Sergey on 27.11.2013 at 10:08 пп ответил:

    А мне понравилось. Автор просто искрит творческим подходом. Желаю удачи!

  7. Sergey on 27.11.2013 at 10:23 пп ответил:

    Даже сильно зацепило! Все учебнике по ****номике, обс* — *т какую-то изюминку. Как-то сильный коллектив, замечательный менеджер, еще чего. А между строк читаешь: минимум вложений, минимум з/п, чтоб не померли с голоду и всё себе, быстрее нахапать и вовремя свалить, пока не оттяпали друзья или враги..
    М. З. предлагает иной путь — творческий. Действительно, не обязательно долго учиться в школе менеджмента, идти в банк клянчить деньги и выполнять все ступеньки по учебникам. Глубокие профессиональные познания в избранной области, талант руководители и неуёмная энергия (трудоголики) самый бесценный капитал, который на песках Сахары выстроит компанелловский город Солнца. Хотя все перечисленные качества — в ущерб себе и своей семье. Ничего не поделать — соотношение неопределённостей не обойти…

    • Gamedis on 27.11.2013 at 10:27 пп ответил:

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

  8. Sergey on 28.11.2013 at 8:21 пп ответил:

    «Час Быка» — сейчас не время вычислять и устранять. Пора спасать самое ценное — душу…

Добавить комментарий

Навигация