В репрессивной модели управления лидер будет, как правило, подбирать сотрудников либо глупее себя, либо таких, которых он может «загипнотизировать» или шантажировать тем или иным образом. Тут ищут «псов», которыми легко управлять и которыми легко травить. Спускаемые сверху идиотские указания будут без изменений проксироваться вниз и те, кто сможет проксировать их ниже — выживают, остальные лопаются. habr.com/post/124716Все ли так плохо с тим-лидерством? Навязывать ли скрам формально, когда его потребность никто не понимает, и она не особо ощущается, или вводить его элементы постепенно, чтобы команда почувствовала его эффективность.
Конфликты интересов частая ситуация в рабочих коллективах и не только в программистских. И зачастую нет правых и виноватых, есть столкновение опыта и видений. Как раскрыть потенциал всех сотрудников и получить синергию, когда 1+1 = 11, а не 2.
Навеяло после футбольного чемпионата мира по футболу. История вывода на колею скрама. Все события вымышлены, все совпадения случайны. Обобщенная и сильно упрощенная ситуация.
Итак, команда сформирована, аналитик, фронтендер, фуллстек-бекендер. Не скрам. Команда сформирована с достаточно грамотным и разносторонне развитым и опытным тимлидером, который имеет широкие полномочия. Руководство компании делегирует ему полную власть.
Для аналогии, представим, что проект — это лига по футболу. всей команды с фейлом, то есть неудавшимся или надолго затянувшимся проектом. Успехом считается качественно выполненный и вовремя сданный продукт, то есть верхнее положение команды в чемпионате по результатам всех игр. Игры — это спринты. Спринт — итерация в скраме, в ходе которой создается рост программного обеспечения. Жестко фиксирован по времени, как и матч в футболе. Обзор первого матча (спринта), ситуация вполне реальная.
Начало работы на проектом (Первый тайм, все идет хорошо, гол счет 1 — 0)
Итак свисток, и достаточно опытные в индивидуальном плане игроки, но не сыгранные вместе, очень хорошо делают свое дело. Аналитик ставит задачи, фронтендер делает приложение на моковом бекенде. По началу все идет хорошо, верстка, архитектура проекта, быстро создаются страницы, заказчик быстро получает результаты, команда получает от него обратный фидбек. Все довольны.
Бекенд развивается отдельно, строится архитектура, закладывается база данных, прокидываются примерные методы.
Неклиентоориентированный бекенд (Опасный момент, гол, передачи плохо проходят в среднюю зону, 1 — 1)
Аналитик проявляя очень хорошие индивидуальные качества, передает задачу команде, экран и описание.
Фронтендер, получает пас, верстает форму, пишет клиентский код, передает пас фулстеку-бекендеру. И ожидает что то вроде:
GET /some/method
Фуллстек-бекендер(капитан команды, он же тим-лид) принял пас и отдает:
Как правило, фуллстеки имеют неглубокие знания в областях (просто по причине того что физически не могут все охватить глубоко), но видят весь проект в целом. Они хороши на небольших проектах, где все делают сами, и в командной разработке неэффективны.
Возникла пауза и недоумение, на вопрос почему так, молчание и игнор, тим-лидер знает что делает. При повторных таких передачах и последующих вопросах, почему так. Ответ: «Доверся мне, я знаю, что делаю, у тебя нет видения системы в целом». Пока ничья 1-1. И ничего тут сделать нельзя, ни фронтендеру, ни руководству.
Слабое командное взаимодействие (Опасный момент, гол, 2-1 факап ведет)
Фронтендер думает и напрягается. Что нужно прокинуть на экран? Переспрашивает, но взаимодействие не клеится. Тим-лидер-фуллстек-бекендер нервничает, сыпяться ответы. «Думай!». «Мне проще самому сделать», «Пипец». Игра не клеится, команда пропускает второй гол.
Усиление средствами командной разработки (Время идет не в пользу команды, 2-1 счет прежний)
Фронтендер понемногу догадываться о параметрах, научился предугадывать направление паса, но все равно был брак в игре. Фронтендер плохо воспринимает все на слух, и просит средства командной разработки (Redmine, Jira, Trello). Руководство идет на встречу. Начали ставится задачи, типа:
Приветствие -> ??? (какое поле взять из данных)
Параметр1-> ??? (какое поле взять из данных)
Параметр2 -> ??? (какое поле взять из данных)
Данные для ясности чистятся прямо приходу из бекенда и в понятном виде прокидываются в html. Игра стабилизировалась, но уходит время, счет прежний в пользу факапа.
Травма, рефакторинг кода, (Команда отыгрывается, но и пропускает гол 3-2)
Фронтендер получает травму и покидает поле на некоторое время (запланированный отпуск), в это время бекендер, залезает в код фронта, тратит время на его рефакторинг, и героически распутывает данные из бекенда прямо в html. Быстрый гол, здорово! Но в ответ получает баги от аналитика и невыполненные задачи по текущему спринту. Да… команда быстро получила ответный гол. Бекендер попадает список лучших бомбардиров. Фронтендер быстро восстановился и снова в игре. Но так как пасы не идут, а тим лид сам справляется, то фронт пока не сильно задействован. Финальный свисток, матч окончен. 3-2 команда проиграла, но впереди следующие игры (спринты).
Ретроспектива спринта (Анализ первой игры, фронтендер на скамейке запасных)
В скраме для выявления проблем на ранних этапах и гибкой самонастройки команды, проводятся ретроспективы спринтов, которые проводит скрам-мастер (тренер команды), но так как его нет в клубе. Фронтендер инициирует ее. Собирает всех участников, и объясняет ошибочность от отказа игры в пас, так как один момент не может улучшить игру команды на протяжении всего чемпионата (окончания проекта), и просит высказаться всех членов команды. В ответ капитан команды — тимлид — фуллстек, предлагает перевести фронтендера на другой проект, так как мнения игроков никого не волнуют. Команда молчит — руководство клуба тоже. Трансфер пока затянулся, фронтендер завис на скамейке запасных.
Как действовать руководству клуба? Тим лидер или скрам мастер? Открытые обсуждения, высказывание мнений или единоличные приказы тим лида. На самом деле тут нет правильного ответа. Для прояснения ситуации нужно ввести тестировщика и посмотреть на игру в еще нескольких спринтах. Все зависит от размеров проекта.
Комментарии (16)
OlegKrasikov
28.08.2018 16:53В скраме для выявления проблем на ранних этапах и гибкой самонастройки команды, проводятся ретроспективы спринтов
То есть вы утверждаете, что после ранних этапов ретро не нужно?
mazhekin Автор
28.08.2018 16:58я не написал что ретро на поздних этапах не проводится, я имел ввиду ретро для раннего выявления проблем, чем раньше тем лучше, а не в конце проекта
OlegKrasikov
28.08.2018 19:09Но это же опять что-то не то. Ретро не может по определению скрамгайда проходить в конце проекта. Если это так, это не скрам, а какой-то другой, свой Agile-фреймворк на основе скрама. Скрамгайд четко регламентирует ретро:
Ретроспектива Спринта — это возможность для Скрам-команды провести инспекцию,
направленную на себя, и создать план улучшений командной работы в следующем
Спринте.
Ретроспектива Спринта проводится после Обзора Спринта и перед Планированием
следующего Спринта. Максимальная продолжительность Ретроспективы – 3 часа для
Спринта длительностью один месяц. Для более коротких Спринтов, как правило, отводится
меньше времениmazhekin Автор
28.08.2018 19:25-2Помоему на практике главная цель ретроспективы, выявить отклонения в разработке проекта, и запаздывания, а улучшение работы команды это дело второе. Если через пару-тройку спринтов выявляется хроническое невыполнение задач, или ничего толком до конца не доделывается (некачественно, с багами, вроде много сделано но ничего толком), то нужно принимать кардинальные меры вплоть до отказа от проекта или замены участников команды. Очень много командных фейловых стартапов, которые тянутся очень долго, люди вангуют, расходуются огромные средства, и в конце концов все лопается. И причем это должны выявлять скрам мастера как можно скорее.
OlegKrasikov
28.08.2018 19:37+1улучшение работы команды это дело второе
Коллега, извините, но у вас нет понимания, что такое Scrum.
Скрам — это фреймворк, который обладает собственными правилами. Если вы работаете по скраму, то принимайте их. Если не принимаете, не называйте это Scrum. Сбертех придумал свой Сберджайл и им никто и никогда не сможет предъявить, что они работают не по скрамгайду, потому что у них не скрам.
вроде много сделано но ничего толком
Почитайте, опять же, скрамгайд: что такое PBR, что такое gold plating и не спирайте, пожалуйста, свое незнание на Scrum
mazhekin Автор
28.08.2018 19:58-2Ну в гайде описаны оптимистические сценарии. А в жизни команда может бесконечно проводить ретроспективы и улучшать свои условия работы за счет заказчика. И не продвигатся в выполнении проекта.
OlegKrasikov
28.08.2018 21:24+1Я сделаю последнюю цитату и на этом, думаю, стоит закончить:
Роли, артефакты, правила и события Скрама не подлежат
изменению. Хотя использование отдельных элементов данного фреймворка допустимо,
но полученный результат не может называться Скрамом. Скрам существует только
в качестве цельного фреймворка, но он может вмещать в себя другие техники,
методологии и практики.
mazhekin Автор
29.08.2018 03:55Я тоже приведу цитату одного из основателей методологии скрама Джеффа Сазерленда:
Наблюдать. Ориентироваться. Решать. Действовать.
medium.com/@analysisparadisis/обзор-книги-scrum-джеффа-сазерленда-38f64706bdfb
ggo
29.08.2018 10:57То что делала команда, это не скрам.
Как должно было быть:
Фронтендер на дейли сообщает свой статус, и неблагоприятный прогноз.
Команда понимает, что есть проблема. И в течении дня устраивает краткий митинг с участием заинтересованных лиц. Обсуждают как решить проблему и уложиться в срок. Вариантов решения много, зависит от контекста.
На ретро теоретически может встать вопрос, как не наступить на эту же проблему повторно. А может и не встать. Все зависит от влияния и частоты.
Про бекендера, который правит код на фронте. Это вообще не про скрам.
Типичная ИТ-проблема. Решается типичными ИТ-решениями (тесты, ревью и т.п.). И не важно что бекендер залез во фронт. Вместо бекендера мог быть джун фронтендер, и т.д.
time2rfc
вот после этого предложения, закралось ощушение что не на те рельсы скрама вы встали
mazhekin Автор
изначально это был не скрам
time2rfc
Многие компании проходят трансформации, но это же не значит, что люди остаються в ролях менеджеров, тимлидов. Как говориться, с таким настроением — слона не продать. Пересесть на рельсы это не только ритуально шапочки переименовать но и с другой стороны посмотреть на привычные вещи. Не критики вашего опыта ради, не повторения другими для.
з.Ы.
Очень странный тимлид, который не мог только нужные поля отдать, но это уже отдельная история.
JediPhilosopher
Ну тут как раз вполне мог быть вопрос с опытом и бОльшим пониманием того, во что превратиться проект в будущем. Грубо говоря, заказчик говорит «хочу авторизацию пользователя». Фронтендер это понимает «должен быть метод, в который передаешь логин-пароль, а тебе в ответ „да“ или „нет“». А тимлид на таких проектах уже собаку съел и знает, что всегда потом захочется иметь разные группы пользователей, разделение доступа, всякие кастомные списки прав и т.п., и закладывает все это сразу в формате данных, чтобы потом два раза не бегать.
Другое дело что конечно отказ от объяснений и срачи — вот это уже некрасиво.
time2rfc
Это более чем некрасиво.
По кому звонил колокол — по командной работе в коллективе с таким тимлидом.
По личным наблюдениям два-три средних человека с хорошим уровнем коммуникации очень легко обгоняют маститых и опытных мастодонтов.
mazhekin Автор
Тут описана попытка перевода с тимлида на скрам. Причем не формально, а решая конкретные проблемы.
time2rfc
Надеюсь что этот опыт не отобьет у вас попытку попробывать еще раз но уже без тим.лида.