Comments 57
В таких случаях я всегда говорю — без фанатизма. Один знакомый тимлид как то за чашкой чая рассказал, что он проанализировал, что стендап митинги длятся долго. И он принял решение стоять с секундомером, давая каждому минуту на доклад.
Как так можно напрягать команду? Это же постоянное напряжение. Зачем, что бы выиграть 5 минут?
У мебя в команде я наоборот веду политику, спокойствия, дружеского отношения и доверия. И мы очень редко выходим за 10 — 15 минут. Но зато я знаю, что все вопросы, замечания и предложения будут озвучены. Люди довольны, всем комфортно.
Поэтому, все эти штуки придумали нельзя, но не надо управлять ради власти и управления. Ведь это должно помогать, а не напрягать.
Как так можно напрягать команду? Это же постоянное напряжение. Зачем, что бы выиграть 5 минут?
У мебя в команде я наоборот веду политику, спокойствия, дружеского отношения и доверия. И мы очень редко выходим за 10 — 15 минут. Но зато я знаю, что все вопросы, замечания и предложения будут озвучены. Люди довольны, всем комфортно.
Поэтому, все эти штуки придумали нельзя, но не надо управлять ради власти и управления. Ведь это должно помогать, а не напрягать.
Да, согласен! Все хорошо в меру.
В команде очень важно общаться. Если вы чувствуете, что что-то напрягает или процесс просто не работает, то нужно об этом говорить. А в обязанности тим лида, в том числе, входит и необходимость слушать своих подопечных.
В команде очень важно общаться. Если вы чувствуете, что что-то напрягает или процесс просто не работает, то нужно об этом говорить. А в обязанности тим лида, в том числе, входит и необходимость слушать своих подопечных.
А я наоборот соглашусь с «знакомым тимлидом». У нас митинги тоже затягиваются и это реально бесит. Причем по идее сказать пару слов о сделанном и о планах — на это много времени не надо, минуты вполне хватает при ежедневных собраниях. А вот если кто-то начинает излишние подробности излагать (ну есть такие люди которые не умеют кратко говорить), или спорить друг с другом — вот так это все на час и затягивается. А остальные сидят и скучают.
Все долгие моменты можно обсудить либо лично, либо на каком-нибудь отдельном собрании, где будут только те кому это интересно. А общие собрания должны быть максимально короткие.
Все долгие моменты можно обсудить либо лично, либо на каком-нибудь отдельном собрании, где будут только те кому это интересно. А общие собрания должны быть максимально короткие.
Поддержу. Основная проблема — формат митинга. Должен быть точная повестка и формат изложения для каждого участника, тогда затягиваться сильно не будет.
Пример — ретроспектива на 20 человек раз в неделю. Если проводить её в свободном формате — то каждый будет рассказывать про какую-то конкретику по своим задачам, в целом скорее всего не интересную остальным или интересную, но не с такими подробностями. Явно не меньше 5 минут, а в среднем минут 7-8. 20 человек * 8 минут = прощайте два с половиной часа.
Изначально так и было. Долго, малоэффективно. Меняем формат — каждый человек к ретроспективе должен подготовиться и ответить на два вопроса: что в общем процессе работы команды на этом спринте было самым положительным моментом и что было самым отрицательным. Все, по-очереди, отвечаем на эти вопросы — фиксируем на доске.
Решаем несколько проблем — 1) отсекаем неважное, все могут сказать только одну вещь, думают и выкладывают самое важное. 2) готовятся заранее, нет моментов когда один человек думает — 20 ждут. 3) каждый обязательно высказывается и всё фиксируется у всех перед глазами, тезисы четкие и не требуют доработки. 4) обсуждаем общий процесс, а не конкретные проблемы.
Занимает от 30 секунд до полутора минут на человека. Без обсуждений, чисто постановка проблемы. Итого 15-25 минут. После чего когда все высказались — на доске у всех перед глазами есть "проблематика", инициируем обсуждение и решение по проблемам, подмечаем сильные моменты в работе. В этот момент, по каждой проблеме команда думает вместе, никто не "засыпает" выслушивая неинтересные чужие проблемы, предлагаются решения, фиксируются. Если обсуждение занимает больше 5 минут — ставится задача "обсудить отдельно заинтересованным", к следующей ретроспективе результаты. Это занимает еще 30-40 минут.
Итого: вместо 2,5-3 часов — час или час с копейками, все проблемы зафиксированы и видны всем, долгие обсуждения вынесены в отдельные группы, отсечено всё неважное и не относящееся к общей работе команды.
Причины у затяжных стендапов может быть две: 1) команда элементарно не готовится (за 5-10 минут до мита нужно открыть трекер и освежить в памяти что я делал вчера, что буду сегодня и какие проблемы), 2) начинается обсуждение проблемы в рамках стендапа. Если проблема большая, сначала завершаем со стендапом, затем оставляем на обсуждение только заинтересованных. При соблюдении этих простых правил за 15 минут вывалиться можно только если в команде больше семи человек, а это уже сигнал, что лучше организовать две команды из трёх-четырёх.
Они заставляли меня ходить на митинги полные пустых разговоров.
Не понимаю почему считается что разработчику ненужно участвовать в митингах.
Без них у него не будет представления о развитии проекта, какой должен быть конечный результат, не получиться по максимуму использовать опыт разработчиков, может с текущими проблемами кто то уже сталкивался раньше. Опять же это полезный опыт.
Я пришел к тому что в митингах полезно участвовать. И полезно понимать общие проблемы и вектор движения проекта. Приведенная цитата отражает мое отношение к этому в прошлом.
Но все же не все митинги бывают полезными. Проблема в том, что есть тенденция перетирать на митингах уже известные вещи. Мало новой инфорации. Еще одна проблема — односторонние митинги, когда ты не можешь сразу дать свой фидбек.
Но все же не все митинги бывают полезными. Проблема в том, что есть тенденция перетирать на митингах уже известные вещи. Мало новой инфорации. Еще одна проблема — односторонние митинги, когда ты не можешь сразу дать свой фидбек.
Я понял что вы хотели сказать в статье.
Просто меня удивляет общая тенденция, да и практика тоже, что программистам митинги не нужны, потому я и выделил вашу строку.
Просто меня удивляет общая тенденция, да и практика тоже, что программистам митинги не нужны, потому я и выделил вашу строку.
Но все же не все митинги бывают полезными.Это да. Но как по мне нельзя однозначно сказать что хуже — потерянное время на прослушивание уже известных вещей или отсутствие информации о развитии проекта.
Просто меня удивляет общая тенденция, да и практика тоже, что программистам митинги не нужны
Вероятно ноги растут из излишнего фанатизма или некоторого ЧСВ программистов выше джунов. Такое наблюдал неоднократно:
«Я программист, я созидатель, я творю, я один понимаю как и решаю как оно должно быть, а все вокруг только мешаются».
Ну и митинги, в принципе бывают разные. Так-же лично присутствовал на совещании, которое собирал начальник производтвенного отдела, на которое были созваны начальники всех отделов, ведущие инженеры и генеральный. Совещание длилось полтора часа из которых почти половину времени обсуждали дефицит шайб.
Не совсем про разработку ПО, но аналогии можно провести.
Вероятно ноги растут из излишнего фанатизма или некоторого ЧСВ программистов выше джуно
В моем понимании это связано больше с тенденцией делать только то, что предполагает роль (хотя это можно отнести к фанатизму). И это наблюдается не только у программеров.
Например, я работал с аниматором, которому было западло однотипно называть файлы анимаций, чтобы их было легко загрузить из кода. Он сказал «Я аниматор, я хочу анимировать, а не файлики переименовывать».
По аналогии и программеры поступают. «Я программист, хочу код писать, а не на митинги ходить и таски заводить».
Просто меня удивляет общая тенденция, да и практика тоже, что программистам митинги не нужны, потому я и выделил вашу строку.
Общая тенденция ужасна. Тут я абсолютно согласен.
Это да. Но как по мне нельзя однозначно сказать что хуже — потерянное время на прослушивание уже известных вещей или отсутствие информации о развитии проекта.
Как правило, информацию о развитии проекта можно выбить из определенных людей :) А вот время вернуть сложно. В любом случае можно организовывать митинг в формате «сейчас новая инфа: бла-бла-бла. А теперь остаются те, кто не в курсе последних событий».
Как правило, информацию о развитии проекта можно выбить из определенных людей :) А вот время вернуть сложно. В любом случае можно организовывать митинг в формате «сейчас новая инфа: бла-бла-бла. А теперь остаются те, кто не в курсе последних событий».
Еще бы знать заранее нужна тебе эта информация или нет.
А может наоборот не тебе что то полезное сообщат, а ты чью то глобальную проблему решишь.
Чтобы народ на них с удовольствием ходил, митинг должен иметь кофе-брейк с бутербродами.
Они заставляли меня ходить на митинги полные пустых разговоров.
Не понимаю почему считается что разработчику ненужно участвовать в митингах.
Разработчику не нужно ходить на митинги, полные пустых разговоров.
Без них у него не будет представления о развитии проекта, какой должен быть конечный результат, не получиться по максимуму использовать опыт разработчиков, может с текущими проблемами кто то уже сталкивался раньше
Для этого вполне сгодится пятиминутка раз в неделю. А лучше в две. А если для неё ещё и пиццу заказать :), то разработчики будут ходить туда с радостью, песнями, транспарантами и портретами вождей — ну, митинг же! :).
было
стало
не знаю, умышленно ли «я» сменилось на «мы», но этот прием подчеркивает интересный момент: когда разработчик не заинтересован ни в чем, кроме «писать код», он и не будет следовать ни best practice, ни процессу. и наоборот, заинтересованность в результате приводит к большей организованности.
Я просто хочу писать код.
стало
Мы стали все фиксировать в трекере
не знаю, умышленно ли «я» сменилось на «мы», но этот прием подчеркивает интересный момент: когда разработчик не заинтересован ни в чем, кроме «писать код», он и не будет следовать ни best practice, ни процессу. и наоборот, заинтересованность в результате приводит к большей организованности.
Спасибо за статью! Мне кажется, я понял что такое DevOps (до этого как-то сумбурно представлял). Мне кажется или эта статья подводящая к DevOps? В любом случае, с удовольствием, прочитаю продолжение.
UFO just landed and posted this here
Например, скрам-покер — известный факт что в большинстве случаев, программист over-optimistic при оценке задач, особенно при ограниченном колиестве информации и времени на оценку, а также психологическом давлении при публичном их вынесении, чтобы казаться лучше в глазах коллег и начальства.
Ну ты сам отвечаешь за это. Опять же, всегда можно сказать менеджеру, что ты ошибся. Правильный подход не наказывать за неправильную оценку, а вносить коррективы в оценку на будущее.
Часто сталкиваю с тем, что люди молчат о проблемах и дуются.
UFO just landed and posted this here
Просто посмотрите кто придумал эти методологии. http://agilemanifesto.org/authors.html
Лично мне кажется, что они изначально разрабатывались в помощь программистам. Но все их понимали по-своему и модифицировали, Эти же парни (авторы agile manifesto) были поражены, что появилась такая вещь, как Dark Scrum.
Возможно и мы сами их понимаем неправильно, боясь облажаться перед начальством.
Я работал в геймдеве и прекрасно понимаю о каких переработках идет речь. И я проходил через этот этап, когда я давал оценку, но не мог уложиться, работал на выходных. В конце концов я поговорил со своим менеджером и он меня отругал за это. Сказал, что это не правильно, и нужно корректировать оценку. Или переносить задачу на другой спринт.
Поэтому я могу сделать вывод, что это все зависит от начальства. Хотя и мы сами, если будем говорить о проблемах, можем повлиять на их точку зрения.
Лично мне кажется, что они изначально разрабатывались в помощь программистам. Но все их понимали по-своему и модифицировали, Эти же парни (авторы agile manifesto) были поражены, что появилась такая вещь, как Dark Scrum.
Возможно и мы сами их понимаем неправильно, боясь облажаться перед начальством.
Я работал в геймдеве и прекрасно понимаю о каких переработках идет речь. И я проходил через этот этап, когда я давал оценку, но не мог уложиться, работал на выходных. В конце концов я поговорил со своим менеджером и он меня отругал за это. Сказал, что это не правильно, и нужно корректировать оценку. Или переносить задачу на другой спринт.
Поэтому я могу сделать вывод, что это все зависит от начальства. Хотя и мы сами, если будем говорить о проблемах, можем повлиять на их точку зрения.
UFO just landed and posted this here
«Меньше кормить» — иметь меньшую команду при тех же результатах.
Мое видение меньше кормить — это набрать в проект junior менеджеров и программистов а ждать от них результата как от топовой команды сеньоров.
Вы забыли одну важную вещь написать. Люди как сверху вниз так и снизу вверх должны в команду быть отобраны такими, чтобы заботились друг о друге. И чтобы дух сотрудничества не затмевался духом соревнования, манипуляции и ненависти.
… но не надо управлять ради власти и управления. Ведь это должно помогать, а не напрягать.Именно ТАК делают карьеру. Стремясь с помощью управления доказать прежде всего свою личную небходимость и с помощью игры на публику/(фальшивой)дружбы с руководством/интриг/манипуляций прити к власти/добиться личного роста. И да, либо личная карьера, либо хороший результат.
Честно говоря я не встречал прямо таки нездоровой конкуренции между разработчиками. Командные игроки выгоднее для проекта, чем «звезды-одиночки».
+100
Но это зависит от людей. Люди все разные, и в команду может свободно попасть человек-менеджер (термин не совсем правильный, но другого нет), который занимается личной карьерой. И всё, команда начинает играть по его правилам.
Но есть ещё один нюанс — когда в теме появляются деньги, то туда махом слетаются человеки-менеджеры, и вскоре контора будет состоять целиком из них.
Но это зависит от людей. Люди все разные, и в команду может свободно попасть человек-менеджер (термин не совсем правильный, но другого нет), который занимается личной карьерой. И всё, команда начинает играть по его правилам.
Но есть ещё один нюанс — когда в теме появляются деньги, то туда махом слетаются человеки-менеджеры, и вскоре контора будет состоять целиком из них.
Все зависит от проекта и задач.
Если только начинается разработка и цена ошибки не так велика и тем более свой собственный проект — ни к чему формальности. Нужно быстро запуститься и посмотреть на результат.
Если это итерпрайз, котрый програмирует космические спутники на заказ — то тут крутится большое количество бабла и большая ответственность. Написание кода будет составлять 20% (условно) от всех усилий ибо будут вечные согласования, переписывания документации, десятки менеджеров и начальников.
Выбор остается за каждым — иметь очень не эффективную но крайне надежную разработку с кучей промежуточных звеньев, или иметь высокий кпд разработки, небольшой бюджет, но при этом самому быть разработчиком, что бы полностью понимать что происходит иначе легко свернуть не туда и виноватых потом не найти.
Я склоняюсь ко второму варианту ибо если ничего не понимаешь в разработке — нечего в разработку лезть и обставляться вокруг себя промежуточными звеньями с таким же уровнем непонимания.
Если только начинается разработка и цена ошибки не так велика и тем более свой собственный проект — ни к чему формальности. Нужно быстро запуститься и посмотреть на результат.
Если это итерпрайз, котрый програмирует космические спутники на заказ — то тут крутится большое количество бабла и большая ответственность. Написание кода будет составлять 20% (условно) от всех усилий ибо будут вечные согласования, переписывания документации, десятки менеджеров и начальников.
Выбор остается за каждым — иметь очень не эффективную но крайне надежную разработку с кучей промежуточных звеньев, или иметь высокий кпд разработки, небольшой бюджет, но при этом самому быть разработчиком, что бы полностью понимать что происходит иначе легко свернуть не туда и виноватых потом не найти.
Я склоняюсь ко второму варианту ибо если ничего не понимаешь в разработке — нечего в разработку лезть и обставляться вокруг себя промежуточными звеньями с таким же уровнем непонимания.
А как же банки? Сбербанк практикует Agile. Надежность для них крайне критична. Бабло, ответственность, все дела.
Про аджайл в сбербанке знают только Греф и те кто вокруг него. В офисах от этого далеки :-)
Не соглашусь. Наблюдаю как потребитель. Реально люди не ограничиваются своими инструкциями и креативно мыслят, чего не ожидаешь от банковских служащих. Похожие изменения пошли на почте. Реально пытаются строить бирюзовые организации.
То что они развиваются — это бесспорно. Более того, несмотря на всю костность структуры сбер проделал титаническую работу что бы быть таким гибким насколько это возможно.
Ни одна другая гос (или приближенная к государству) компания с таким количеством людей и бюрократии не достигла таких высот гибкости.
Ни одна другая гос (или приближенная к государству) компания с таким количеством людей и бюрократии не достигла таких высот гибкости.
Весь Сбербанк не практикует Agile и не будет его практиковать ещё года два-три-пять, как бы этого не хотел Греф. Agile требует перестроения мышления каждого сотрудника (больше того: культуры!), перестроения бизнес-процессов, перестроения организационной структуры. В организации такого масштаба это легко может растянуться на десятилетие — пока люди перевоспитаются (или уволятся), пока организацию перекроишь…
Конечно сложно сдвинуть что-то гигантское. Но положительный тренд уже прослеживается. Если банки смотрят в эту сторону, то значит Agile может отвечать всем требованиям качества/безопасности.
Кстати, еще вспомнил про Альфа-банк. Они не так давно писали про их Agile.
Кстати, еще вспомнил про Альфа-банк. Они не так давно писали про их Agile.
В организации, где целью является получение прибыли, сложно внедрять Agile
Вообще, во всех организациях, кроме благотварительных, цель — получение прибыли. Agile как раз про это, ведь он позволяет оперативно реагировать на изменения рынка/требований. Внедрять Agile сложно в организациях, где правят староверы или где разработка — не основной вид деятельности.
Есть достаточно примеров коммерческих организаций, в том числе весьма успешных, не имеющих целью получение прибыли. Мне нравится такое сравнение: прибыль как дыхание, без него жизни нет, но оно не может быть целью жизни. Прибыль как цель — что в коммерческом, что в личном смысле — устаревающая концепция.
Проблема всех методик, в том что идиоты следуют им не разобравшись.
Как с традициями — в основе большинства традиций лежит некое событие, которое показало что надо делать так, а не иначе. Но потом про событие забылось, а «делай так» осталось.
Что мы имеем на выходе? Карго культ и всё. Который не работает, а только жрет ресурсы и мешает.
Если бы все методики применялись с пониманием — не было бы проблем. И отторжения у разработчиков тоже не было бы.
Как с традициями — в основе большинства традиций лежит некое событие, которое показало что надо делать так, а не иначе. Но потом про событие забылось, а «делай так» осталось.
Что мы имеем на выходе? Карго культ и всё. Который не работает, а только жрет ресурсы и мешает.
Если бы все методики применялись с пониманием — не было бы проблем. И отторжения у разработчиков тоже не было бы.
Если менеджер не уважает программистов, которые пишут код, то не имеет значения, что внутри — ватерфалл, аджайл или телефонное право.
Если уважает — аналогично.
То есть проблема токсичных компаний состоит в том, что менеджер боится программистов (которые знают больше него), а программисты не чувствуют уважения (т.к. менеджер из страха вынужен использовать формальные метрики и игнорировать всё, что говорят программисты).
Мораль: если ты менеджер — слушай программистов и уважай то, что они говорят.
Если ты программист — объясняй, а если не слушают — ищи другую работу.
Если ты начальник над менеджером (начальник отдела/CTO/CEO/etc) — гони прочь менеджера, который не уважает программистов.
Если уважает — аналогично.
То есть проблема токсичных компаний состоит в том, что менеджер боится программистов (которые знают больше него), а программисты не чувствуют уважения (т.к. менеджер из страха вынужен использовать формальные метрики и игнорировать всё, что говорят программисты).
Мораль: если ты менеджер — слушай программистов и уважай то, что они говорят.
Если ты программист — объясняй, а если не слушают — ищи другую работу.
Если ты начальник над менеджером (начальник отдела/CTO/CEO/etc) — гони прочь менеджера, который не уважает программистов.
Проблема отсутствия уважения существуют с двух сторон. Программисты тоже часто не уважают менеджеров просто за тот факт, что они менеджеры. Но в целом я согласен. В этом плане CTO во многом может на все влиять.
Чем грамотнее менеджер в техническом плане тем больше понимания того что он делает и к чему это приведет и тем больше стоит его слушать разработчикам ибо разработчики не знают многих нюансов, когда сдвинуть на 1 пиксель иконку — это самая важная задача когда на продукт смотрит ген директор заказчика.
При малой грамотности наоборот менеджеру слушать разработчика надо.
Вообще это разные люди и нельзя требовать от одних полноценных знаний другого профиля. Нужно уметь перекладывать нужные задачи на плечи нужных людей — это крайне сложно, особенно разработчикам, которые в принципе все сами могут сделать.
При малой грамотности наоборот менеджеру слушать разработчика надо.
Вообще это разные люди и нельзя требовать от одних полноценных знаний другого профиля. Нужно уметь перекладывать нужные задачи на плечи нужных людей — это крайне сложно, особенно разработчикам, которые в принципе все сами могут сделать.
Если мы не говорим про тривиальные изменения, то менеджер не может знать что творится у разработчиков, даже если он сам из бывших разработчиков. Потому что очень часто возражения или предложения идут не от экзистенциального, а от очень практичного. Может быть, так, что для сдвига иконки на один пиксел надо переписать пол-приложения, потому что используемый фреймворк такого не умеет. И толковый менеджер должен в этой ситуации не «продавить», а спросить «а как мы можем сделать чтобы это было на один пиксел левее?». И, возможно, окажется, что проще перерисовать иконку за 5 минут, чем ломать архитектуру на протяжении двух месяцев.
Вот чтобы спросить — вот тут вот уважение и нужно. А у разработчиков должно быть уважение к менеджеру, чтобы не бояться говорить «можно вот так вот», даже если «вот так вот» грозит ужасом и авралами (распространённый метод саботажа «с низу» — не рассказывать про возможные решения, если решения грозят геморроем на местах).
Второй признак токсичности (кроме неуважения) — это когда разрабочик не может сказать «я этого не знаю». Когда все всё знают и все чёткие ровные, обычно образуется крайне резкая и жёсткая среда, при которой удачные технические ршения не выживают.
Вот чтобы спросить — вот тут вот уважение и нужно. А у разработчиков должно быть уважение к менеджеру, чтобы не бояться говорить «можно вот так вот», даже если «вот так вот» грозит ужасом и авралами (распространённый метод саботажа «с низу» — не рассказывать про возможные решения, если решения грозят геморроем на местах).
Второй признак токсичности (кроме неуважения) — это когда разрабочик не может сказать «я этого не знаю». Когда все всё знают и все чёткие ровные, обычно образуется крайне резкая и жёсткая среда, при которой удачные технические ршения не выживают.
И толковый менеджер должен в этой ситуации не «продавить», а спросить «а как мы можем сделать чтобы это было на один пиксел левее?»
Согласен. Но и толковый программист, если заинтересован в успехе проекта, должен предложить альтернативные решения.
Вообще, так как программист лучше всего осведомлен о текущем состоянии проекта, мне кажется, это обязанность программиста — предупреждать о возможных рисках/проблемах, и предлагать варианты решения. Менеджер же не должен пропускать это мимо ушей, должен принимать конкретные решения и дейтвовать.
Слишком многое из того, что мы называем менеджментом, представляет собой помехи, которые мешают людям работать. Питер Друкер
На сегодняшний день существует несчетное количество инструментов и методик. Все они, по-своему, отличаются и имеют свои достоинства и недостатки.
Зрелость тимлида\DevOp'а\менеджера определяется набором инструмента в его арсенале. Умение определить задачи команды и выбрать подходящий инструмент, технику или концепсию.
Недостаточно просто прочитать очередную статью о новой модной методологии и заставить свою комманду следовать ей.
Задача инструмента — облегчать работу и если он подобран правильно, он незаметен. Он просто помогает тебе делать своё дело, он — как еще один орган твоего тела, специально обученый выполнять определенную задачу. Ты просто рефлексорно им пользуешься.
Бывают случаи, в которых, вроде бы подходящий на первый взгляд инструмент, должен работать, но КПД низкий. Причин на это может быть огромное количество, и не всегда они видны невооруженным взглядом. Особенности сферы деятельности, кол-во сотрудников в команде, их взаимотношения, георасположение, отсутвие базового понимания назначения инструмента, банальное отсутсвие мотивации или просто желание быть бунтарём и отвергать любые нововведения. Последнее особенно проблематично, если человек достаточно харизматичен и способен склонить к этому остальных участников команды.
Задача менеджемнта (человек в любой должности, ответственный за внедрение новых инструментов) вовремя обнаружить проблемы в интеграции тех или иных техник\инструментов, установить причину и предпринять необходимые меры. Не боятся пробовать новые инструменты и избавляться от существующих, несмотря насколько они хайповые на данный момент.
Если, все условия выполнены, команда будет тратить бОльшую часть времения для усовершенствования продукта\сервиса.
Зрелость тимлида\DevOp'а\менеджера определяется набором инструмента в его арсенале. Умение определить задачи команды и выбрать подходящий инструмент, технику или концепсию.
Недостаточно просто прочитать очередную статью о новой модной методологии и заставить свою комманду следовать ей.
Задача инструмента — облегчать работу и если он подобран правильно, он незаметен. Он просто помогает тебе делать своё дело, он — как еще один орган твоего тела, специально обученый выполнять определенную задачу. Ты просто рефлексорно им пользуешься.
Бывают случаи, в которых, вроде бы подходящий на первый взгляд инструмент, должен работать, но КПД низкий. Причин на это может быть огромное количество, и не всегда они видны невооруженным взглядом. Особенности сферы деятельности, кол-во сотрудников в команде, их взаимотношения, георасположение, отсутвие базового понимания назначения инструмента, банальное отсутсвие мотивации или просто желание быть бунтарём и отвергать любые нововведения. Последнее особенно проблематично, если человек достаточно харизматичен и способен склонить к этому остальных участников команды.
Задача менеджемнта (человек в любой должности, ответственный за внедрение новых инструментов) вовремя обнаружить проблемы в интеграции тех или иных техник\инструментов, установить причину и предпринять необходимые меры. Не боятся пробовать новые инструменты и избавляться от существующих, несмотря насколько они хайповые на данный момент.
Если, все условия выполнены, команда будет тратить бОльшую часть времения для усовершенствования продукта\сервиса.
я регулярно сталкиваюсь с командами, которые следуют всем церемониям скрама, начисто забывая про его дух. Например, есть все положенные роли и митинги, но процесс не итеративный и клиент не то что не присутствует, а даже не определен. Особенно ярко это проявляется в госсекторе и науке где рынок не карает тебя за ошибки
В статье описан типичный ход мыслей программера по мере его развития. У меня всё было точно так же :)
В этот момент я осознал, что все эти процессы, которые мне казались бюрократией, были придуманы людьми не просто так.
Парадокс, но находятся люди с не меньшим опытом, но так и не осознавшие эту истину.
Вдвойне парадокс, но некоторые из этих людей — менеджеры разработки…
Sign up to leave a comment.
Узники системы