Предисловие
Не секрет, что правильно выстроенные бизнес-процессы нужны всем.
Отдельные граждане, отделы и целые компании с холдингами бегают кругами и воют о необходимости правильного обустройства всех и всяческих процессов. Всё должно быть посчитано, измерено, запланировано и выполнено в срок, в строгих рамках бюджета. Метрики и KPI, предсказуемость и прозрачность. Везде должен быть “внедрён” Agile. Все должны мыслить категориями Lean. Все должны думать о Business Value. И, будучи разбуженными ночью, — мгновенно ответить на вопрос: “каков LTV нашего пользователя?”
Отличный, рациональный подход.
В разработке программного обеспечения давно и прочно обосновался тренд “не изобретай велосипеда”.
Нужно разработать инсталлятор для нашего мега-продукта? Интегрироваться с внешней системой? Разработать кучу отчётов?
Не умничай, бери коробочное решение. Сэкономишь кучу времени, нервов, и, как результат, — денег компании.
А если помножить это на тенденцию снижения среднего уровня технической квалификации инженерных кадров, — это отдельная тема, завязанная на многолетнее превышения спроса над предложением, — то вообще получается отлично. Поминутно вейпая и попивая смузи, можно строить целые системы, просто интегрируя готовые блоки при помощи
Поэтому — не изобретай велосипеда и не умничай. Используй готовое, а
Отличный, рациональный подход.
Но самое забавное, как всегда, — то, что может случиться на стыке двух отличных, рациональных принципов. Давайте попробуем рассмотреть абстрактный пример, выгодно оттеняющий всю глубину этой проблемы.
Итак, знакомьтесь с нашими героями
Компания Anytime Rational Inc.
До мозга костей рациональна, следует обоим принципам. Вся по Agile, везде Scrum, каждый разработчик точно знает, какой Business Value имеет каждая его задача. Все озабочены повышением эффективности, общим индексом счастья и прибылью организации.
Не компания, а сказка. Любой владелец IT-бизнеса, глядя на неё, пускает слюнки. Сплошная конфетка.
Ведь таких отличных компаний в реальном мире просто не существует.
Компания Somehow Someway Ltd
.Ну, здесь, — традиционный бардак. Инженеры поминутно травят свои инженерные байки в курилках, любят инженерные задачи, и чихать хотели на User LIfetime Value. Время от времени изобретают велосипеды, хотя в целом держатся в тренде “повторного использования” сторонних компонент.
На словах в компании Scrum, и даже есть итерации. На деле же, — разработка ведётся, как бог на душу положит.
Словом, — чего уж там. Обычная инженерная компания.
Для упрощения нашего сферического коня в вакууме, — обе компании занимаются примерно одним и тем же, перед ними возникают примерно одинаковые задачи, и работают в них инженеры и менеджеры примерно одного уровня.
Так, конечно, не бывает, но правильные подходы должны же, при прочих равных, показывать преимущества Ratio над броуновским движением человеческой материи, верно?
Итак, в обеих компаниях на низовом уровне, в процессе работы над некоей фичей, возникает инженерная проблема. Один из компонентов ведёт себя непредсказуемо, — старая добрая проблема “протекающих абстракций”, помноженная на проблему интеграции, — и инженер, работающий над фичей, не понимает, почему это происходит.
Хронология проблемы
Day 1
В Anytime Rational инженер, — скажем, Пётр Первый, — сообщает о возникшей проблеме на утреннем стендапе. Скрам мастер уточняет, сколько времени может потребоваться на её устранение. Инженер затрудняется ответить и запрашивает микроспринт на изучение. Владелец продукта говорит, что фича, в общем-то, второстепенная, и выделить больше двух дней он не может. Скрам мастер сокрушается, что общая скорость команды в этом спринте упадёт, — но выделяет Петру микроспринт.
В Somehow Someway перед инженером, — для простоты Петром Вторым, — встаёт точно такая же проблема.
На стендапе он привычно отбарабанивает: “сегодня продолжаю работать над таской SM-134, помощь не требуется”. Он не особо задумывается над смыслом своих слов. Ведь весь его мозг поглощён обдумыванием “этой херни, которая происходит в долбаном модуле, написанном криворукими даунами из Third Party Component Solutions”.
На очередном перекуре он издалека задаёт вопрос ведущему системщику Ярославу Мудрому из смежного отдела, и они, неспешно покуривая, минут 20 обсуждают подробности. Ярослав даёт пару советов, но в глубине души знает, что Пётру они не помогут. Потому что Пётр, конечно, классный парень и всё такое, — но дизассемблер Ярослав ему бы ни за что не доверил.
Day 2
Anytime Rational
Пётр Первый ковыряется со своей проблемой уже второй день. Он понимает, что микроспринт, видимо, будет профукан, и на утреннем стендапе говорит, что ему необходима помощь.
“Кто тебе для этого нужен?” — участливо спрашивает скрам мастер.
“В идеале, — Ярослав Мудрый из смежного отдела. Он крутой системщик, и это как раз его профиль” — отвечает Пётр Первый, уже точно зная ответ на этот запрос.
“Оооо, Ярослааав..” — огорчённо тянет скрам мастер, — “ты же знаешь, он очень занят серьёзнейшими задачами, которые очень важны для нашей компании.”
“У тебя же есть ещё один день”, — встревает владелец продукта, — “Давай посмотрим, что получится по результатам микроспринта, и будем принимать решение.”
Somehow Someway
Пётр Второй в это время, безуспешно перепробовав всё, что посоветовал ему Ярослав, задумчиво дымит в курилке.
“Чего такой смурной?” — благодушно интересуется зашедший на дымок тимлид Иван Грозный.
“Да так… одна херовинка тут..” — мнётся Петр. Ивана Васильевича он уважает, но побаивается, и расписываться в своей неспособности решить задачу не очень-то спешит.
“Ну-ну”, — хитро усмехается Иван, — “небось, опять взялся за дело не по своей квалификации?”
Иван, посмеиваясь, удаляется, а посрамлённый Пётр идёт ковыряться дальше.
Day 3
Anytime Rational
“Микроспринт не принёс результатов”, — сообщает Петр Первый. “Мне не удалось докопаться до источника проблемы. Требуется либо привлечение Ярослава, либо дополнительное время на изучение.”
“Ты и так уже два дня..” — начинает закипать владелец продукта, но скрам мастер умело перехватывает управление потенциальным конфликтом.
“Как мы и договорились, был проведён микроспринт на изучение проблемы, и теперь нам необходимо принять решение. Мы либо выделяем дополнительное время на изучение, либо запрашиваем помощь у отдела системной разработки, либо эскалируем проблему и предоставляем принятие решения вышестоящему руководству.”
“А что мы будем эскалировать?” — буркает недовольный владелец продукта. “Какова стоимость решения проблемы? Мы же так ничего и не выяснили.”
“Хорошо, значит, у нас остаётся два варианта.” — примирительно улыбается скрам мастер. “Будем запрашивать помощь или продолжим разбираться сами?”
Все выжидательно смотрят на Петра. Он нервно сглатывает, но, будучи верным сторонником идеалов Agile, честно и открыто сообщает, что ему нужна помощь.
“Отлично.” — говорит скрам мастер, делая пометку в Evernote. “Я узнаю у отдела системной разработки, когда они смогут нам с этим помочь.”
“Пётр, пока что переключайся на следующую по приоритету задачу. Так, это у нас… SM-135, если я не ошибаюсь.”
Someway Somewhat
Пётр Второй, привычно отбарабанив дежурную фразу, продолжает размышлять над поведением модуля, зафиксированным вчера вечером. Однако Иван прерывает его размышления.
“Пётр, а как там твоя проблемка? Уже решил?”
“Эмм… пока нет, сегодня ещё попробую пару подходов..” — глаза Петра избегают внимательного, с прищуром, взгляда Ивана.
“Ну-ну..” — без улыбки произносит Иван.
Day 5
Anytime Rational
Пётр Первый увлечённо работает над новой задачей. Он понимает, что до codefreeze осталось совсем немного времени, но стремится закончить хоть что-то в этом спринте, чтобы скорость команды не просела слишком сильно, и релиз продукта вышел с хорошим набором фичей.
Скрам мастер пытается согласовать совместный микроспринт с командой Ярослава, но приоритеты их задач существенно выше, так что перспектива выглядит достаточно безрадостной.
Но Пётр доволен. Наконец-то можно хотя бы на время забыть об этой сложной проблеме, и принести реальную пользу команде и компании в целом.
Somewhat Somewhere
Петр Второй, поминутно матерясь, сидит за своим рабочим столом, неощутимо слушает в наушниках какой-то тяжеляк и пытается разобраться, “что же, мать его, происходит внутри этой грёбаной помойки!”
На одном экране открыт отладчик, на другом, — дизассемблированный код. Сосредоточенный взгляд Петра постепенно наполняется безнадёгой, и левый глаз уже начинает подёргиваться.
Он не замечает, что за его спиной вот уже десять минут задумчиво молчит Ярослав, — покуда тот, наконец, не похлопывает Петра по плечу.
“А? Что? Какого..” — срывает с головы наушники Пётр. “А, Ярослав… ты чего тут?”
“Да вот, думал тут над твоей проблемкой на досуге… кстати, смотри, тебе бы вот здесь JNE пробросить, — а то ты дальше не продвинешься.”
“Где? А, вот тут вот… и что это даст? Ааа, вона как..” — Пётр снова входит в поток. “А это тут что за хрень?”
“Кривая работа с регистрами. Давай вот так попробуем..” — подключается к нему Ярослав.
Day 10
Anytime Rational
“Итак, скорость нашей команды в этом спринте упала на 3 стори поинта. Учитывая, что фича SM-134 была нами в итоге выброшена из спринта, — это вполне ожидаемо. Кстати, Пётр, ты молодец, я не ожидал, что ты успеешь реализовать SM-135.” — скрам мастер привычно проводил ретроспективу, когда в комнату стремительно влетел Ярослав.
“Ребята, я буквально на минуту, извините. Микроспринт согласован, на три дня мы вам выделим Ефима. Он хороший системщик, вдвоём с Петром проблему наверняка успешно решите. Ну, всё, я побежал, извините ещё раз, что прервал ваше ретро.”
Пётр Первый растерянно хлопает глазами. Проблема? Ах, да, вон та, страшная и сложная… бррр…
Somewhere Someone
“Пётр, что там с твоей проблемой??” — грозно вопрошает Иван.
“Нормально всё, Иван Васильевич. Один небольшой глюк остался, — ну, и код потом вылизать. Дня за три точно управлюсь.” — спокойно отвечает Пётр Второй.
“Знаю я твои три дня..” — ворчит Иван. “Давай быстрее заканчивай, у меня уже руководство интересуется, почему мы эту фичу так сильно затягиваем. Скоро ведро вазелина надо будет заготавливать!”
“Да знаю я, Иван Васильевич. Затащим!” — улыбается Пётр.
Day 13
Anytime Rational
“По результатам микроспринта с Ефимом оказалось, что на решение проблемы потребуется ещё половина спринта. Или даже целый спринт.” — не вполне уверенно говорит Пётр Первый. Вдвоём с Ефимом они ковырялись над этой проблемой три полновесных дня, но уверенного решения так и не нашли. — “Есть несколько наметок..”
“Наметок, шнаметок!” — взрывается владелец продукта, — “Где решение? Ты точно за неделю это сделаешь??”
“Так, коллеги, давайте успокоимся.” — вмешивается скрам мастер, укоризненно глядя на владельца продукта. “Пётр, я правильно понимаю, что за половину спринта ты можешь не успеть, но уж за целый спринт точно решишь проблему?”
“Да, всё верно.” — отвечает Пётр, пытаясь говорить уверенно.
“Это всё хорошо и здорово, конечно.” — немного успокоившись, рассуждает владелец продукта. “Но готовы ли мы тратить дополнительное время на эту фичу? Мы и так уже потратили силы и время. Мне кажется, надо эскалировать. Рациональность дополнительных затрат лично мне кажется неочевидной.”
“Хорошо, давайте так и сделаем.” — подытоживает скрам мастер.
Someone Sometime
“Ну, я тут почти закончил. Всё работает, только subroutine бы ещё причесать.” — отчитывается Пётр Второй. “Благо, скиллы по C я мальца подтянул, там фигня осталась.”
“Ну, вот и молодец.” — улыбается Иван. “Причёсывать-то обязательно, или просто очень хочется? Может быть, лучше фичу наконец-то закроешь?”
“А как же моё чувство прекрасного?” — показушно оскорбляется Пётр, потрясая в воздухе руками.
Все инженеры дружно ржут.
Day 17
Anytime Rational
“Руководство пришло к выводу, что возобновлять работу над фичей в данный момент нерационально. Business Value не настолько велико, чтобы вкладывать в неё дополнительные ресурсы, да и по срокам получается, что к следующему релизу никак не успеваем.” — сообщает владелец продукта.
“Ну, и слава богу.” — бурчит себе под нос довольный Пётр Первый. “Можно забыть, как страшный сон.”
Sometime Something
“Пётр, фича твоя идёт в релиз. Тестами-то покрыл?” — интересуется Иван.
“Ну, так… надо бы ещё добавить..” — мнётся Пётр Второй.
“Вот и добавь.” — веско говорит Иван. “Всё, разошлись, работаем.”
Итог
Опытные разработчики знают, что самые сложные проблемы возникают на стыке технологий и модулей, при интеграции, — там, где встречаются две разных системы. При этом обе системы по отдельности могут быть отличными, — прекрасно разработанными, прекрасно работающими. Но на стыке двух прекрасных систем зачастую возникают уродливейшие противоречия.
Внимательный читатель заметит, что и в нашей истории проблема Anytime Rational возникает на стыке двух прекрасно работающих систем — продаж и производства.
Поэтому, когда вы в следующий раз будете вопрошать: “почему, ну почему они не реализовали здесь эту очевидную фичу??”, или “какого чёрта это работает через такую глубокую задницу??” — помните, что дело может быть в протекающих абстракциях на стыке двух и более систем.
Хотя может быть, в конкретном встреченном вами случае дело просто в рукожопости быдлокодеров, разрабатывающих левой пяткой какое-то говно.
Комментарии (60)
a40
02.10.2017 10:22+8Счастливая история о том, как Ярославу Мудрому хватило «десяток минут», чтобы задать правильный вектор Петру второму.
А в жизни не всё решается десятком минут. Как насчет дня-полутора? И тут Ярослава Мудрый мог бы и не выделить столько время со своих задач. И сидел бы Петр Второй долго-предолго.
wispoz
02.10.2017 10:38+3Я бы сказал что Петру Второму повезло, что Ярослав обратил свой взор на эту проблему.
NickPasko Автор
02.10.2017 16:37+1Ну, для начала Ярослав пообщался достаточно подробно о сути задачи с Петром.
Потом покрутил эту проблему в бэкграунде. И пришёл к нему постоять за спиной уже не с пустой головой.
В случае же первой компании он вообще не вникал в суть.
boblenin
02.10.2017 20:57+1В жизни Петр Второй побоялся бы рассказать, что у него затык на такой простой задаче. Подумал бы что он м… к и бился бы головой об задачу неделю. Потом бы все проклял и решил бы уволиться.
Но автор подгоняет сказку под ответ. Потому все как во властелине колец. Когда полная засада, из рукава выныривает оживший внезапно Гендальф да не просто так а на гиганских птичках.
vyatsek
05.10.2017 20:54А в жизни не всё решается десятком минут. Как насчет дня-полутора? И тут Ярослава Мудрый мог бы и не выделить столько время со своих задач. И сидел бы Петр Второй долго-предолго.
На это есть тех лид который должен управлять ресурсами: задача Пети передается Ярославу, часть задач Ярослава раскидывается на кого-то еще, есть и куча других вариантов.
SirEdvin
02.10.2017 10:56+5Вся разница состоит в том, что второй компании повезло, а первой — нет.
Я слабо представляю себе компании вот совсем без перекуров или совместных обедов, а значит обсуждения все равно есть. И внезапно помочь Ярослав Мудрый как бы мог попробовать и в первом случае, вместо перекура.Daniil1979
02.10.2017 11:18Тут не только в везении дело, но и в отношениях между людьми.
SirEdvin
02.10.2017 11:19+3То есть в первой компании отношения между людьми тоже 100% стерильные? Вы в это верите?
Ну и как бы этот Ярослав Мудрый шатался бы по залу, если бы был сильно загружен? Проваливал бы свои задачи, что бы решить неважные? Тогда я тем более за первый вариант.qwertyRu
02.10.2017 11:50То есть в первой компании отношения между людьми тоже 100% стерильные
Запросто может быть. Руководство набирало и «воспитывало» сотрудников в стиле «ТОЛЬКО ПЛАН И НИ ЧЕГО ЛИЧНОГО!», перекуры и обеды по расписанию, каждые N часов персональный отчет о том что сделано, работы с персоналам нет, только делай план и думай как компанию сделать богаче. Поощряются конфликты между сотрудниками, т.к. это «повышает конкуренцию»и пр. тимбилдинг.
Тогда вполне возможно, что когда скажут что Ярослав может решить проблему, то Ярослав будет отнекиваться до последнего, что бы «утопить конкурента»SirEdvin
02.10.2017 12:31Стоп-стоп. Как связано поощрение нездоровой конкуренции и тимбилдинг? Если компания все будет делать по учебникам, то в тех же учебниках написано, что конфликты между сотрудниками — это плохо и их нужно гасить и вообще строить приятную корпоративную политику.
qwertyRu
02.10.2017 12:40Виноват, тимбилдинг надо было взять в кавычки.
В контексте комментария имелись ввиду такие мероприятия «крысиные бега», публичные наказания (они бывают, нужны но как крайняя мера) и пр.SirEdvin
02.10.2017 12:43Я просто не совсем понимаю, как это связано с правильно поставленными процессами?
Более того, в этой компании точно такого нет, так как Петр Первый сам признается в проблеме, причем заранее. Явно не похоже на конкурентную среду.qwertyRu
02.10.2017 12:57комментарий относился к фразе
«вы верите что отношения могут быть стерильные»
и комментарий не подразумевал отношения в фирме.
Хотя если учесть что на третий день:
“Ты и так уже два дня..” — начинает закипать владелец продукта, но скрам мастер умело перехватывает управление потенциальным конфликтом.
Он (Петр Первый) нервно сглатывает, но, будучи верным сторонником идеалов Agile, честно и открыто сообщает, что ему нужна помощь.
оставляет пространство для полета фантазии об отношениях в фирме. Например по последней цитате, как бы поступил Петр Первый, если бы не был верен идеалам?SirEdvin
02.10.2017 13:02+1> оставляет пространство для полета фантазии об отношениях в фирме. Например по последней цитате, как бы поступил Петр Первый, если бы не был верен идеалам?
Как Петр Второй, который тянет до последнего и в итоге его спасла только счастливая случайность в виде праздно шатающегося по офису крутого специалиста, которого или не догрузили задачами, или он работает спустя рукава.qwertyRu
02.10.2017 13:14только в рамках предположений.
Петр Второй коммуникабельный человек и имеет хорошие отношения со многими сотрудниками, Ярослав курил несколько раз один и решил уточнить у приятеля чем он все таки занят, увидел проблему, которая его заинтересовала как специалиста и подключился.SirEdvin
02.10.2017 13:18-1Это отлично, но проблема в том, что если бы у Ярослава была бы сложная задача, он вряд ли бы вот так просто пошел бы в Петру разбираться в его задачах, потому что это требует переключение контекста и вникания в проблему.
Или Ярослав готов решать проблемы других людей, несмотря на то, что вполне может подвести из-за этого свою команду? Ведь, как уже указывали, история о том, что этот Ярослав может решить задачу за 10 минут, а в первом случае ему для этого требуется миниспринт выглядит довольно странно.
Shaz
02.10.2017 13:34+1Тут пожалуй стоит учесть что слова Ярослава такие
Да вот, думал тут над твоей проблемкой на досуге… кстати, смотри, тебе бы вот здесь JNE пробросить, — а то ты дальше не продвинешься.”
и это должно нам намекнуть, что Ярослав не в ущерб своим задачам решил проблему Петра.SirEdvin
02.10.2017 13:37То есть Ярослав на досуге, вместо отдыха подумал над задачей, скажем, вместо того что бы поработать над каким-то своим проектом и заняться другими задачами. Это называется повезло.
qwertyRu
02.10.2017 13:35+1Судя по тексту, во второй фирме, на пятый день Ярослав думал о проблеме уже два дня (может он думал по дороге домой-наработу, час в пробках туда, час обратно вот два часа в день). А в первой, на пятый день только начали согласовывать с Ярославом когда он сможет помочь. Вполне может быть, что первые пять дней Ярослав не был занят глобальной проблемой, а на шестой и далее навалилось по полной. И опять же. На в одном случае Ярослав сам пришел, а во втором — отправил сотрудника.
в одном случае — личная инициатива, а во втором — производственная задача, с отчетностью и прочим возможным счастьем.SirEdvin
02.10.2017 13:44+1Да, и отличие личной инициативы от производственной задачи в том, что личная инициатива как бы не обязательна и вообще может и не произойти, а производственная задача всегда так или иначе будет решена.
Я не могу понять, почему первое лучше второго, если второе помимо того, что надежнее, еще позволяет разумно оценить то, насколько оно вообще нужно и контролировать как над задачей идет работа. Вас пугает лишняя бюрократия, на которую у вас должно уходить минут 10-15 максимум, иначе у вас что-то неправильно работает? Так как раз эта бюрократия подстрахует и вас, и ПМ и прочих людей в случае, если вам не повезет, что на мой взгляд, вообще отлично.
qwertyRu
02.10.2017 14:07+2зависит только от личностных качеств.
Если взять за пример данный текст, то можно сделать такое предположение о мотивах Ярослава.
Личная инициатива. Петр нормальный парень, у меня с ним ровные отношения, курим, пьем кофе, общаемся. Он столкнулся с проблемой. Я бы ее решил так или так.
Хм пятый день я не могу с ним по пить кофе и поговорить за жизнь. Что там у него произошло? Зайду посмотрю. О у тебя тут JRE…
Т.к. это добровольная помощь, то Ярослав будет работать так как может работать. Потому что «отчетность» это только репутация в глазах Петра и освобождения его для попить кофе и поговорить, а случае неудачи Ярослав ни чем не рискует. Попутный плюс, о котором Ярослав может явно не думать, но он подразумевается, что Петр становится ему должен.
Производственное распоряжение.
У Ярослава есть задачи за которые с него спросят в конце спринта, может даже строго (например решение проблем завязано на ЗП). Тут ему говорят есть задача, глубины которой ты не знаешь, соответственно не можешь пока представить во что она выльется, вдруг из-за нее не успею что то сделать и будут мозг выносить на планерках, а если там конкретная Ж. То потом решение этой проблемы будет вечным счастьем. Пусть ответственным за ее решение будет другой отдел, а я только помогу есть что. Скрам-мастеру дам кого не жалко, если что, крайним его сделаем а там будет видно.
Словом, есть набор задач которые решает отдел и получает ЗП. И от новых задач которые не ведут к увеличению фонда оплаты труда будут сопротивляться по мере возможности.SirEdvin
02.10.2017 14:16Ваш взгляд можно взять и перевернуть задом наперед:
Личная инициатива.
Петр нормальный парень, у меня с ним ровные отношения, курим, пьем кофе, общаемся. Он столкнулся с проблемой. Я бы ее решил так или так. Хм пятый день я не могу с ним по пить кофе и поговорить за жизнь. Что там у него произошло? Хотя у меня нет времени, тут еще надо добить дела по проекту да и сроки горят, зайду через пару деньков (а получилось недели две, так как на проекте был адский трешак).
Производственное распоряжение.
У Ярослава есть задачи за которые с него спросят в конце спринта, может даже строго (например решение проблем завязано на ЗП). Тут ему говорят есть задача, глубины которой ты не знаешь, соответственно не можешь пока представить во что она выльется, вдруг из-за нее не успею что то сделать и будут мозг выносить на планерках, а если там конкретная Ж. Он говорит это скрам-мастеру, тут оценивает риски и обо всем договаривается с продакт овнером. В итоге все довольны и все заканчивается вовремя.
Я не совсем понимаю, почему вы игнорируете правильно поставленные процессы, а значит то, что на разработчика не просто кидается задача и пусть он варится, а в дополнение к этому еще происходит пересмотр задач и в случае чего сроки двигаются. В первом случае вы целиком зависите от решения Ярослава, и вам повезло, что у него было свободное время и не было завала на проекте, во втором случае задача будет сделана в сроки, или вы об этом сразу узнаете. Все довольны и никаких "мне никто не помог, я тут две недели копался и ничего не получилось".
Опять же, а если бы Петр второй был бы не таким хорошим парнем? Или на работе вот нужно быть со всеми хорошими и заводить дружественные отношения, иначе не выжить?
qwertyRu
02.10.2017 14:38именно поэтому я написал и подчеркнул зависит только от личностных качеств.
И описанная Вами ситуация вполне может быть.
Идеальные процессы хорошо подходят для идеальных задач для идеальных людей. Иначе не было бы столько методологий по управлению проектами.
Могу добавить, что задача будет сделана в сроки, или вы об этом сразу узнаете. Все довольны и никаких «мне никто не помог, я тут две недели копался и ничего не получилось» При поиске бага и его устранению тоже зависит от личностных качеств и атмосферы в компанииSirEdvin
02.10.2017 14:40При поиске бага и его устранению тоже зависит от личностных качеств и атмосферы в компании
В большей степени зависит только от процессов. Если у вас нет каких-то дейли стендапов, то откуда ПМ узнает об этом? Его разработчик будет каждый раз дергать и отвлекать, что бы рассказать свою проблему?
qwertyRu
02.10.2017 14:46Зачем каждый раз? как только поймет что не может решить самостоятельно. И сможет другому специалисту дать технически грамотный ответ, в чем проблема, что делалось и к чему оно привело.
SirEdvin
02.10.2017 19:25И сможет другому специалисту дать технически грамотный ответ, в чем проблема, что делалось и к чему оно привело.
Ни в первом, ни во втором случае грамотного ответа человек дать не может. Какая разница то?
как только поймет что не может решить самостоятельно
Вот во втором случае такого не произошло, такое произошло только в первом. Во втором случае так повезло, что ему помогли.
Bonart
02.10.2017 16:47+1Если у вас нет каких-то дейли стендапов, то откуда ПМ узнает об этом?
К нему придет разработчик и расскажет. Ибо хороший ПМ — лучший друг разработчика. А что дергать и отвлекать — у ПМа должность такая.
Более того — при хороших отношениях и дергать зря не будут, и отказывать в помощи, если дернули.
avost
02.10.2017 21:40+2во втором случае задача будет сделана в сроки, или вы об этом сразу узнаете.
Вообще-то, во втором случае (который по тексту — первый) задача не сделана вовсе. Более того, при данном "правильно поставленном" процессе я вообще не вижу варианта при котором она могла бы быть решена. Разве что у Ярослава Мудрого внезапно кончились бы все задачи вообще, что фантастика. Тщательно прокрутив ситуацию, ещё раз убедился, что "правильно поставленный скрам" является анти-agile процессом.
NickPasko Автор
02.10.2017 16:58-1Хотите ещё наброшу? :)
В первом случае решение задачи было вполне рационально посчитано нерациональным. Т.е. business value не настолько велик, чтобы её вообще реализовывать.
Во втором случае этого никто не считал. В итоге эта задача реализована, — но, похоже, не реализована другая фича (другиЕ фичи?)
По результату в первом случае — бизнес-эффективность, как она есть.
Во втором случае — закрытая сложная инженерная задача.
Что лучше для конечного пользователя? — вопрос спорный.
Но с точки зрения чистого бизнеса, судя по количеству огромных дистрибутивов, жрущих тонны памяти, ЦП и питания, — первый подход куда как лучше.boblenin
02.10.2017 20:53> Что лучше для конечного пользователя? — вопрос спорный.
Если business value низкий — то никакого вопроса. Он определяется в значительной степени потребностями пользователя.
Пример из жизни. Доводилось работать в конторе, где почему-то решили что радиобаттоны должны вести себя как чекбоксы (времена до css). Потрахаться комманде пришлось изрядно. Ценность для пользователя — как у гульки достоинство, техническая сложность — вот она вам пожалуйста.NickPasko Автор
03.10.2017 03:25Да, всё очень сильно зависит от примера.
Приведённый вами — конечно, клинический. )))
Jef239
03.10.2017 04:38+1Ну мы делали что-то в этом роде. Кажется — кнопки на тулбаре с фиксированным нажатым состоянием. Причина простая — при дизайне не поняли размер задачи, а переделывать дизайн во время работы — не захотелось.
Тут нужно найти верный момент, когда стоит подумать: может дешевле переделать дизайн?
balexa
02.10.2017 12:04+4Как-то все притянуто за уши если честно. Возникшая ситуация не имеет ни малейшего отношения к процессам компании. Во второй компании могло не оказаться системщика (что весьма вероятно, вы сами написали что там бардак, весьма вероятно, что он там бы просто не задержался).
И исходя из своего опыта работы в подобных ООО «И так Сойдет», могу сказать, что весьма малая вероятность, что там кто-то бы ковырялся и искал корень проблемы. Замазали бы костылем, проверил бы Петя что «вроде не каждый раз падает» и нехай идет в продакшен.wispoz
02.10.2017 13:29Да и в той которая Agile тоже как-то странно, фича мега важная для бизнеса, разработчик попросил помощь ему только выделили какого-то Эфима.
balexa
02.10.2017 15:49+2Да там все бредово. Начиная с того, что заказчик в первой конторе был неадекватным каким-то (критичная проблема для бизнеса? Аааа, зачем на нее тратить два дня, обещали же что все будет готово!!11один) и еще более неадекватного директора во второй (что Петя, опять занимашьсья какой-то херней и не получается? Ну ладно, занимайся). При таком подходе директора половина народу в конторе будет большую часть рабочего времени смотреть ютуб, а Ярослава будут просить время от времени заставлять настраивать эксель Василисе из бухгалтерии (это кстати одна из причин, почему во второй конторе не будет гениального системщика)
sshmakov
02.10.2017 16:17По условиям задачи как раз не важная.
Day1.
Владелец продукта говорит, что фича, в общем-то, второстепенная, и выделить больше двух дней он не может.
Меня больше занимает вопрос, почему во второй фирме Ярослав помог другу Пете из другого отдела, но в первой не может помочь своему подчиненному Ефиму?
digore
02.10.2017 12:39+3– У нас не получится уложиться в сроки!
– Примените Agile!
– Без достаточного количества людей он нам не поможет!
– Тогда придумайте другое умное слово!helgisbox
02.10.2017 15:49В точку: многие применяют эту процессную модель абы как, лишь бы можно было галочку в протфолио поставить. Мол, вот я такой супер мена менеджер что и вот так могу и еще дюжину англицизмов умею. Страдает только от временщиков-скакунов процесс.
helgisbox
02.10.2017 15:46+1Нормально KPI считается только на линейных производственных линиях, где первый гайки штампует, второй за ним же их штангенциркулем измеряет, а третий заворачивает. На все остальное он «натягивается» с такой гигантской погрешностью, что отчеты времен Брежневской эпохи по сбору мегаурожаев покажутся детскими фантазиями. И толку от таких KPI нет никакого. Это отдельные фантазии, которые к реальности не имеют отношения. Думаю, мега «манагеры» это прекрасно понимают. А раз понимают, то занимаются вредительством осознанно.
a40
02.10.2017 15:48+2Первая компания выглядит положительнее.
Ребята постоянно держали палец на пульсе. Чётко понимали, какие у них проблемы, честно оценивали риски и расставляли приоритеты.
Несомненно, статистически их результат хорош. Хотя на отдельных задачах могут и не оптимально отработать.
dyhmichail
02.10.2017 16:54Как мне показалось проблема очевидна: «Бюрократия умрет с последним человеком».
Ну а если серьезно то со стороны выглядит что дружный коллектив решает проблему эффективнее Scrum методик. Но тогда интересно было бы внести эту плоскость и рассмотреть такой вариант: Дружный коллектив + Без Scrum VS Недружный коллектив / C идеальным ScrumNickPasko Автор
02.10.2017 17:02Верно.
Как выше уже заметили, — Agile ставит людей и коммуникации выше процессов.
«Недружный коллектив с идеальным Scrum» — это карго-культ.
Encarmine
02.10.2017 16:54На мой взгляд представлены единичные случаи, на основе которых судить ни о чем нельзя. При прочих равных команда с построенными процессами будет производить стастистически значимо больше ценности.
Stochkas
02.10.2017 16:54Петр первый больше зарабатывает и меньше может работать.
Петр второй качает скилы и свое самолюбие.
Что лучше спорный вопрос.a40
02.10.2017 17:00Почему первый меньше работать? Он же решил задачу SM-135 вместо того, чтобы буксовать на месте.
Ему просто не дали биться головой об стену.KoCMoHaBT61
02.10.2017 20:50+1Исходя из моей личной практики — решение задачи SM-135, а потом возвращение к предыдущей проблеме может серьёзно помочь решению. Во время долгого анализа глаз замыливается, а возвращение даёт возможность посмотреть свежим взглядом.
boblenin
02.10.2017 20:42+3«В сказке можно покататься на луне. И по радуге промчаться на коне.»
Ну а серьезно. Я надеялся прочитать статью — где кто-то делится граблями по которым они прошли. Ну типа — посмотреть чтобы так не делать. А оказалось — это все то что происходило в голове у автора. А в головах у авторов может происходить все что угодно. В том числе и нерешаемые баги, которые вдруг за 10 минут решаются мегагурьями, которые конечно обладают сокральным знанием, недоступным никому другому.
Ну и вывод. Да scrum не работает в мире где некоторые задачи могут выполнены только магами 50 уровня и никем иначе.NickPasko Автор
03.10.2017 03:29Это не совсем о сакральных знаниях.
Скорее — именно о наблюдениях из жизни, — как идеи Agile могут быть легко подменены процессами. Которые в итоге выхолащивают весь смысл, сводя живые коммуникации между людьми к формальным соблюдениям ритуалов.
На примере сферического коня в вакууме.
Salex_H
03.10.2017 14:58Надо было Петру Первому просить сразу Ефима и не умничать 2 доп дня. Не справились бы с Ефимом, подключили бы Ярослава на 10 минут или скинули бы фичу как неперспективную. Скрам менеджер (или это тимлид такой?) какой-то неопытный… Слабо верится что в такой вумной компании и нельзя вытащить Ярослава официально, обязательно должно быть время когда более опытные люди (или даже свежий взгляд) давали консультации.
speshuric
03.10.2017 20:58+2В первой организации нет ни Agile ни Scrum.
Короткие фиксированные спринты в scrum это очень многосторонний контракт. Судя по всему задачи большого (для scrum) объёма, соответственно команда реально ответственность не принимает, и, кстати, именно необходимость глубокой декомпозиции на целостные задачи 0,5-3 дня (5 дней в крайнем случае) является важным практическим ограничением scrum. Состав спринта менялся на ходу (и судя по всему меняется по каждому чиху).
Ретроспектива проходит с нарушениями. PO — дятел, который умеет долбить команду разработки, но не умеет работать по scrum. SM занимается не тем, чем должен. Ошибки/проблемы не обсуждаются и приоритет не согласуется. Технические решения не обсуждаются.
Технически, если из-за ошибки в third-party прикладному программисту пришлось доставать дизассемблер, чтобы спасти фичу, то это уже fail 80 lvl. С данным объёмом информации сложно сказать в чем именно fail: в архитектуре, в процессах, во взаимодействии, в компетенциях или еще в чем-то. И непонятно, можно ли его исправить (я видел как исправляли и как не исправляли).
Круто. Но это точно не конфетка.
Во второй организации непонятно, что хорошо, а что плохо, что случайно, а что систематично.
vyatsek
05.10.2017 20:49Вообще весь этот скрам и agile выдумка умных продаванов и глупых манагеров.
До прихода Agile Scrum было написано куча различного софта в, том числе и качественного. Потом вдруг откуда ни возьмись, появляется XP, Agile и начинают его насаждать. Что за бред? Покажите мне хоть один проект, который не смог был бы быть напианным без Scrum, а со Scrum его реализация вдруг стала возможной.
Манифест Agile прочеловеческий ресуср совсем не нов и еще во времена СССР рационализаторы и простые рабочие, оценивались как социально, так и финансово. Шутка ли простой рабочий на заводе в 70-80 годах получал 900 рублей в мес и директор завода знал его лично.
Рациональный подход точно так же был всегда, когда взешивались ресурсы и цели(фичи).
Есть ощущение, что с бурным развитием финансов в менеджмент IT компаний пришли какие-то бездари, не имеющие базовых навыков управления и как слесдствие пытающиеся прикрыться процессами.
PS как пример успешного продукта, пошел изучать процессы разработки ядра линукс, а так же попытаюсь найти инфу о том как разрабатывался тот же MS SQL, Visual Studio и другие успешные продукты от MS и не только.
На хабре также была статья про просецц разработки хрома.
Весь скрам укладывается в простое понятие, выдача наиболее значимых фичей на регулярной основе, scrum также позволяет давать некоторую оценку трудозатрат со стороны разработчика, но это было во все времена.
sshmakov
Мне кажется, что здесь проблема возникла из-за того, что процессы Agile поставили выше взаимодействия людей. Что на корню убило саму идею Agile.
NickPasko Автор
Верно.
reinvent
Ну да, система стала мертвой. Если это и есть agile, то печально. Лучше бирюзовые организации строить.
Вообще в основе лежат таланты и коммуникации.
Интересно, помог бы ли решить проблему принцип 80/20 (когда 20 % рабочего времени тратится не на непосредственную работу, а на общее дело, в т.ч. помощь коллегам)?