Комментарии 65
Внимательный читатель заметит, что и в нашей истории проблема Anytime Rational возникает на стыке двух прекрасно работающих систем — продаж и производства.
Мне кажется, что здесь проблема возникла из-за того, что процессы Agile поставили выше взаимодействия людей. Что на корню убило саму идею Agile.
Вообще в основе лежат таланты и коммуникации.
Интересно, помог бы ли решить проблему принцип 80/20 (когда 20 % рабочего времени тратится не на непосредственную работу, а на общее дело, в т.ч. помощь коллегам)?
А в жизни не всё решается десятком минут. Как насчет дня-полутора? И тут Ярослава Мудрый мог бы и не выделить столько время со своих задач. И сидел бы Петр Второй долго-предолго.
Потом покрутил эту проблему в бэкграунде. И пришёл к нему постоять за спиной уже не с пустой головой.
В случае же первой компании он вообще не вникал в суть.
Но автор подгоняет сказку под ответ. Потому все как во властелине колец. Когда полная засада, из рукава выныривает оживший внезапно Гендальф да не просто так а на гиганских птичках.
А в жизни не всё решается десятком минут. Как насчет дня-полутора? И тут Ярослава Мудрый мог бы и не выделить столько время со своих задач. И сидел бы Петр Второй долго-предолго.
На это есть тех лид который должен управлять ресурсами: задача Пети передается Ярославу, часть задач Ярослава раскидывается на кого-то еще, есть и куча других вариантов.
Я слабо представляю себе компании вот совсем без перекуров или совместных обедов, а значит обсуждения все равно есть. И внезапно помочь Ярослав Мудрый как бы мог попробовать и в первом случае, вместо перекура.
Ну и как бы этот Ярослав Мудрый шатался бы по залу, если бы был сильно загружен? Проваливал бы свои задачи, что бы решить неважные? Тогда я тем более за первый вариант.
Запросто может быть. Руководство набирало и «воспитывало» сотрудников в стиле «ТОЛЬКО ПЛАН И НИ ЧЕГО ЛИЧНОГО!», перекуры и обеды по расписанию, каждые N часов персональный отчет о том что сделано, работы с персоналам нет, только делай план и думай как компанию сделать богаче. Поощряются конфликты между сотрудниками, т.к. это «повышает конкуренцию»и пр. тимбилдинг.
Тогда вполне возможно, что когда скажут что Ярослав может решить проблему, то Ярослав будет отнекиваться до последнего, что бы «утопить конкурента»
Стоп-стоп. Как связано поощрение нездоровой конкуренции и тимбилдинг? Если компания все будет делать по учебникам, то в тех же учебниках написано, что конфликты между сотрудниками — это плохо и их нужно гасить и вообще строить приятную корпоративную политику.
В контексте комментария имелись ввиду такие мероприятия «крысиные бега», публичные наказания (они бывают, нужны но как крайняя мера) и пр.
Я просто не совсем понимаю, как это связано с правильно поставленными процессами?
Более того, в этой компании точно такого нет, так как Петр Первый сам признается в проблеме, причем заранее. Явно не похоже на конкурентную среду.
«вы верите что отношения могут быть стерильные»и комментарий не подразумевал отношения в фирме.
Хотя если учесть что на третий день:
“
Ты и так уже два дня..” — начинает закипать владелец продукта, но скрам мастер умело перехватывает управление потенциальным конфликтом.
Он (Петр Первый) нервно сглатывает, но, будучи верным сторонником идеалов Agile, честно и открыто сообщает, что ему нужна помощь.
оставляет пространство для полета фантазии об отношениях в фирме. Например по последней цитате, как бы поступил Петр Первый, если бы не был верен идеалам?
Как Петр Второй, который тянет до последнего и в итоге его спасла только счастливая случайность в виде праздно шатающегося по офису крутого специалиста, которого или не догрузили задачами, или он работает спустя рукава.
Петр Второй коммуникабельный человек и имеет хорошие отношения со многими сотрудниками, Ярослав курил несколько раз один и решил уточнить у приятеля чем он все таки занят, увидел проблему, которая его заинтересовала как специалиста и подключился.
Это отлично, но проблема в том, что если бы у Ярослава была бы сложная задача, он вряд ли бы вот так просто пошел бы в Петру разбираться в его задачах, потому что это требует переключение контекста и вникания в проблему.
Или Ярослав готов решать проблемы других людей, несмотря на то, что вполне может подвести из-за этого свою команду? Ведь, как уже указывали, история о том, что этот Ярослав может решить задачу за 10 минут, а в первом случае ему для этого требуется миниспринт выглядит довольно странно.
Да вот, думал тут над твоей проблемкой на досуге… кстати, смотри, тебе бы вот здесь JNE пробросить, — а то ты дальше не продвинешься.”и это должно нам намекнуть, что Ярослав не в ущерб своим задачам решил проблему Петра.
в одном случае — личная инициатива, а во втором — производственная задача, с отчетностью и прочим возможным счастьем.
Да, и отличие личной инициативы от производственной задачи в том, что личная инициатива как бы не обязательна и вообще может и не произойти, а производственная задача всегда так или иначе будет решена.
Я не могу понять, почему первое лучше второго, если второе помимо того, что надежнее, еще позволяет разумно оценить то, насколько оно вообще нужно и контролировать как над задачей идет работа. Вас пугает лишняя бюрократия, на которую у вас должно уходить минут 10-15 максимум, иначе у вас что-то неправильно работает? Так как раз эта бюрократия подстрахует и вас, и ПМ и прочих людей в случае, если вам не повезет, что на мой взгляд, вообще отлично.
Если взять за пример данный текст, то можно сделать такое предположение о мотивах Ярослава.
Личная инициатива. Петр нормальный парень, у меня с ним ровные отношения, курим, пьем кофе, общаемся. Он столкнулся с проблемой. Я бы ее решил так или так.
Хм пятый день я не могу с ним по пить кофе и поговорить за жизнь. Что там у него произошло? Зайду посмотрю. О у тебя тут JRE…
Т.к. это добровольная помощь, то Ярослав будет работать так как может работать. Потому что «отчетность» это только репутация в глазах Петра и освобождения его для попить кофе и поговорить, а случае неудачи Ярослав ни чем не рискует. Попутный плюс, о котором Ярослав может явно не думать, но он подразумевается, что Петр становится ему должен.
Производственное распоряжение.
У Ярослава есть задачи за которые с него спросят в конце спринта, может даже строго (например решение проблем завязано на ЗП). Тут ему говорят есть задача, глубины которой ты не знаешь, соответственно не можешь пока представить во что она выльется, вдруг из-за нее не успею что то сделать и будут мозг выносить на планерках, а если там конкретная Ж. То потом решение этой проблемы будет вечным счастьем. Пусть ответственным за ее решение будет другой отдел, а я только помогу есть что. Скрам-мастеру дам кого не жалко, если что, крайним его сделаем а там будет видно.
Словом, есть набор задач которые решает отдел и получает ЗП. И от новых задач которые не ведут к увеличению фонда оплаты труда будут сопротивляться по мере возможности.
Ваш взгляд можно взять и перевернуть задом наперед:
Личная инициатива.
Петр нормальный парень, у меня с ним ровные отношения, курим, пьем кофе, общаемся. Он столкнулся с проблемой. Я бы ее решил так или так. Хм пятый день я не могу с ним по пить кофе и поговорить за жизнь. Что там у него произошло? Хотя у меня нет времени, тут еще надо добить дела по проекту да и сроки горят, зайду через пару деньков (а получилось недели две, так как на проекте был адский трешак).
Производственное распоряжение.
У Ярослава есть задачи за которые с него спросят в конце спринта, может даже строго (например решение проблем завязано на ЗП). Тут ему говорят есть задача, глубины которой ты не знаешь, соответственно не можешь пока представить во что она выльется, вдруг из-за нее не успею что то сделать и будут мозг выносить на планерках, а если там конкретная Ж. Он говорит это скрам-мастеру, тут оценивает риски и обо всем договаривается с продакт овнером. В итоге все довольны и все заканчивается вовремя.
Я не совсем понимаю, почему вы игнорируете правильно поставленные процессы, а значит то, что на разработчика не просто кидается задача и пусть он варится, а в дополнение к этому еще происходит пересмотр задач и в случае чего сроки двигаются. В первом случае вы целиком зависите от решения Ярослава, и вам повезло, что у него было свободное время и не было завала на проекте, во втором случае задача будет сделана в сроки, или вы об этом сразу узнаете. Все довольны и никаких "мне никто не помог, я тут две недели копался и ничего не получилось".
Опять же, а если бы Петр второй был бы не таким хорошим парнем? Или на работе вот нужно быть со всеми хорошими и заводить дружественные отношения, иначе не выжить?
И описанная Вами ситуация вполне может быть.
Идеальные процессы хорошо подходят для идеальных задач для идеальных людей. Иначе не было бы столько методологий по управлению проектами.
Могу добавить, что задача будет сделана в сроки, или вы об этом сразу узнаете. Все довольны и никаких «мне никто не помог, я тут две недели копался и ничего не получилось» При поиске бага и его устранению тоже зависит от личностных качеств и атмосферы в компании
При поиске бага и его устранению тоже зависит от личностных качеств и атмосферы в компании
В большей степени зависит только от процессов. Если у вас нет каких-то дейли стендапов, то откуда ПМ узнает об этом? Его разработчик будет каждый раз дергать и отвлекать, что бы рассказать свою проблему?
И сможет другому специалисту дать технически грамотный ответ, в чем проблема, что делалось и к чему оно привело.
Ни в первом, ни во втором случае грамотного ответа человек дать не может. Какая разница то?
как только поймет что не может решить самостоятельно
Вот во втором случае такого не произошло, такое произошло только в первом. Во втором случае так повезло, что ему помогли.
Если у вас нет каких-то дейли стендапов, то откуда ПМ узнает об этом?
К нему придет разработчик и расскажет. Ибо хороший ПМ — лучший друг разработчика. А что дергать и отвлекать — у ПМа должность такая.
Более того — при хороших отношениях и дергать зря не будут, и отказывать в помощи, если дернули.
во втором случае задача будет сделана в сроки, или вы об этом сразу узнаете.
Вообще-то, во втором случае (который по тексту — первый) задача не сделана вовсе. Более того, при данном "правильно поставленном" процессе я вообще не вижу варианта при котором она могла бы быть решена. Разве что у Ярослава Мудрого внезапно кончились бы все задачи вообще, что фантастика. Тщательно прокрутив ситуацию, ещё раз убедился, что "правильно поставленный скрам" является анти-agile процессом.
В первом случае решение задачи было вполне рационально посчитано нерациональным. Т.е. business value не настолько велик, чтобы её вообще реализовывать.
Во втором случае этого никто не считал. В итоге эта задача реализована, — но, похоже, не реализована другая фича (другиЕ фичи?)
По результату в первом случае — бизнес-эффективность, как она есть.
Во втором случае — закрытая сложная инженерная задача.
Что лучше для конечного пользователя? — вопрос спорный.
Но с точки зрения чистого бизнеса, судя по количеству огромных дистрибутивов, жрущих тонны памяти, ЦП и питания, — первый подход куда как лучше.
Если business value низкий — то никакого вопроса. Он определяется в значительной степени потребностями пользователя.
Пример из жизни. Доводилось работать в конторе, где почему-то решили что радиобаттоны должны вести себя как чекбоксы (времена до css). Потрахаться комманде пришлось изрядно. Ценность для пользователя — как у гульки достоинство, техническая сложность — вот она вам пожалуйста.
Приведённый вами — конечно, клинический. )))
Тут нужно найти верный момент, когда стоит подумать: может дешевле переделать дизайн?
Day1.
Владелец продукта говорит, что фича, в общем-то, второстепенная, и выделить больше двух дней он не может.
Меня больше занимает вопрос, почему во второй фирме Ярослав помог другу Пете из другого отдела, но в первой не может помочь своему подчиненному Ефиму?
– Примените Agile!
– Без достаточного количества людей он нам не поможет!
– Тогда придумайте другое умное слово!
Ребята постоянно держали палец на пульсе. Чётко понимали, какие у них проблемы, честно оценивали риски и расставляли приоритеты.
Несомненно, статистически их результат хорош. Хотя на отдельных задачах могут и не оптимально отработать.
Ну а если серьезно то со стороны выглядит что дружный коллектив решает проблему эффективнее Scrum методик. Но тогда интересно было бы внести эту плоскость и рассмотреть такой вариант: Дружный коллектив + Без Scrum VS Недружный коллектив / C идеальным Scrum
Петр второй качает скилы и свое самолюбие.
Что лучше спорный вопрос.
Ну а серьезно. Я надеялся прочитать статью — где кто-то делится граблями по которым они прошли. Ну типа — посмотреть чтобы так не делать. А оказалось — это все то что происходило в голове у автора. А в головах у авторов может происходить все что угодно. В том числе и нерешаемые баги, которые вдруг за 10 минут решаются мегагурьями, которые конечно обладают сокральным знанием, недоступным никому другому.
Ну и вывод. Да scrum не работает в мире где некоторые задачи могут выполнены только магами 50 уровня и никем иначе.
Короткие фиксированные спринты в scrum это очень многосторонний контракт. Судя по всему задачи большого (для scrum) объёма, соответственно команда реально ответственность не принимает, и, кстати, именно необходимость глубокой декомпозиции на целостные задачи 0,5-3 дня (5 дней в крайнем случае) является важным практическим ограничением scrum. Состав спринта менялся на ходу (и судя по всему меняется по каждому чиху).
Ретроспектива проходит с нарушениями. PO — дятел, который умеет долбить команду разработки, но не умеет работать по scrum. SM занимается не тем, чем должен. Ошибки/проблемы не обсуждаются и приоритет не согласуется. Технические решения не обсуждаются.
Технически, если из-за ошибки в third-party прикладному программисту пришлось доставать дизассемблер, чтобы спасти фичу, то это уже fail 80 lvl. С данным объёмом информации сложно сказать в чем именно fail: в архитектуре, в процессах, во взаимодействии, в компетенциях или еще в чем-то. И непонятно, можно ли его исправить (я видел как исправляли и как не исправляли).
Круто. Но это точно не конфетка.
Во второй организации непонятно, что хорошо, а что плохо, что случайно, а что систематично.
До прихода Agile Scrum было написано куча различного софта в, том числе и качественного. Потом вдруг откуда ни возьмись, появляется XP, Agile и начинают его насаждать. Что за бред? Покажите мне хоть один проект, который не смог был бы быть напианным без Scrum, а со Scrum его реализация вдруг стала возможной.
Манифест Agile прочеловеческий ресуср совсем не нов и еще во времена СССР рационализаторы и простые рабочие, оценивались как социально, так и финансово. Шутка ли простой рабочий на заводе в 70-80 годах получал 900 рублей в мес и директор завода знал его лично.
Рациональный подход точно так же был всегда, когда взешивались ресурсы и цели(фичи).
Есть ощущение, что с бурным развитием финансов в менеджмент IT компаний пришли какие-то бездари, не имеющие базовых навыков управления и как слесдствие пытающиеся прикрыться процессами.
PS как пример успешного продукта, пошел изучать процессы разработки ядра линукс, а так же попытаюсь найти инфу о том как разрабатывался тот же MS SQL, Visual Studio и другие успешные продукты от MS и не только.
На хабре также была статья про просецц разработки хрома.
Весь скрам укладывается в простое понятие, выдача наиболее значимых фичей на регулярной основе, scrum также позволяет давать некоторую оценку трудозатрат со стороны разработчика, но это было во все времена.
Традиционно принято считать, что окончательно эти принципы сформировались на заводах Toyota, и многое было взято, в том числе, из производственных подходов СССР.
Если так разобраться, то:
Lean = Agile, это общий набор принципов.
XP, Scum, Kanban, — набор рекомендаций.
Custom Agile, вырабатываемый на каждом конкретном предприятии — это методология. Она может быть задокументирована, может быть просто частью культуры производства, — не так важно.
Важно другое: бездумное «внедрение Agile» в любой организации — это карго культ. Если внедрена методология под любым названием, нарушающая базовые принципы Agile подходов, — то система будет неэффективной.
Если внедрена методология под любым названием, нарушающая базовые принципы Agile подходов, — то система будет неэффективной.
Слишком сильное утверждение, не находите?
С практической точки зрения, к сожалению, получается, что «внедряют Agile» — по названию, нарушая при этом принципы Agile. И получают на выходе карго-культ, позволяющий гордо бить себя пяткой в грудь: «мы ВНЕДРИЛИ Agile». А что там под капотом, — мало кто понимает, и почему это получается неэфективно, — тоже мало кто понимает.
ЗЫ Вероятно, мне надо было выразиться точнее: «Если внедрена якобы Agile методология под любым названием, нарушающая базовые принципы Agile подходов...»
Сказка о хорошо выстроенных бизнес-процессах, или как одна проблема хакнула идеально работающую систему разработки