Привет! Меня зовут Ваня. За последние 10 лет меня покидало по разным специализациям. Я занимался и фул стек веб-разработкой, и мобильными приложениями, а последние лет 5 — играми. Теперь вот в Microsoft занесло. Хочу поделиться историей о том как менялось мое отношение к разным особенностям профессии.
Когда я был еще личинкой разработчика, я любил программирование больше всего на свете. Возможность писать код (Да еще и получать за это деньги!) туманила разум. Получив свою первую профессиональную работу веб-разработчиком, я был на седьмом небе от счастья и не мог поверить, что так бывает. Но не все так просто...
В этой бочке нашлась ложка дегтя — менеджеры.
Выкидыши системы. Они не понимали и не хотели понимать почему фичу, которую они просят, нельзя сделать быстро. А я не хотел объяснять. Я хотел писать код. Хотел чтобы мне не мешали. Они заставляли меня создавать задачи в трекере и логгировать время. Они заставляли меня ходить на митинги полные пустых разговоров. Зачем все это?
Я просто хочу писать код. Почему я должен общаться с этими людьми? Они не понимают и десятой части того, о чем я говорю. Как было бы хорошо избавиться от всей этой бюрократической чуши! Игры! В разработке игр наверняка нет всей этой ереси!
Глоток свободы
И вот, спустя несколько лет я попал в мир грез. Разработка игр. Я устроился в новообразовавшуюся студию. Кроме меня и моей начальницы больше никого не было. Она мне дала общее описание проекта. Никаких деталей. И сказала, мол, начни делать что-нибудь. Неделю я просто писал код, работая над прототипом. Никаких митингов, никаких таск-трекеров, никаких отчетов. С меня ничего не спрашивали. Я подумал: "Боже, я что в рай что ли попал?". Свобода!
Мы реализовывали все клевые идеи, которые только появлялись в нашей голове. Было весело. Но однажды на нас сверху спустили требования и сроки. Все изменилось. Объем работы вырос. Я один не справлялся. Мы наняли несколько разработчиков.
Мы делили работу между собой, но работали очень неформально. Сроки, конечно, были, но никто не дышал в затылок. В какой-то момент я заметил, что мы часто обсуждаем важные детали устно. Это приводило к тому, что мы забывали что-то доделать, или забывали о некоторых задачах и багах совсем. Они просто терялись.
Мы хаотично переключались от багов к задачам и наоборот. Это подтолкнуло нас к первому шагу в сторону порядка — таск трекер. А ведь я так это не любил. Мне всегда это казалось чисто формальным и совсем не нужным.
Мы стали все фиксировать в трекере. Со временем. Стали меньше забывать о чем-то. Мы не теряли баги. В хаосе появился кусочек порядка. Мы начали фокусироваться только на самых важных задачах. Мы стали понимать сколько успеем за неделю.
В этот момент я осознал, что все эти процессы, которые мне казались бюрократией, были придуманы людьми не просто так.
Погружение
Не знаю, то ли это я стал опытнее, то ли это бремя ответственности за проект, свалившееся на меня как на лида. Но я начал понимать, что мы тратим кучу времени на какие-то левые вещи.
Пока мы разрабатывали игрушку, очень важно было постоянно получать фидбек, чтобы двигаться в правильном направлении. Мы постоянно собирали билды и выкладывали их на портал, чтобы люди могли поиграть. Фактически, мы работали по Agile схеме. Но у нас не было стендапов. Спринта официально тоже не было, но мы работали итерациями длиной в неделю. Спринт планнинг был условным, а ревью и ретроспективы не было совсем. Иначе говоря, у нас не было митингов с кучей пустой болтовни, и я не заметил какого-либо ущерба от этого.
Разработка прототипа предполагает, что все делается очень быстро. А это означает и частую сборку билдов для демонстрации проделанной работы. В то время мы писали на C++, и время сборки билда нас удручало. В конце концов у нас бомбануло от того что билд нужно собирать несколько раз в день. Мы поставили билд сервер и настроили:
- сборку билда по коммиту
- деплой билда в демо-портал
- уведомление о том, что билд не собрался и список предполагаемых виновников
Сколько времени освободилось! Больше не надо было прерываться посреди задачи, чтобы собрать билд для "шишек", которые хотят его посмотреть прямо сейчас.
С появлением билд сервера пришла новая проблема. Билд стал часто ломаться. Хотя мы и могли сказать "Берите предыдущий билд, последний пока не работает" — это был не самый удобный вариант.
Проблема заключалась в том, что все коммитили в master. Многие коммитили не убедившись, что их коммит не поломал билд. Или не привнес регрессионный баг. Чтобы побороть эту проблему, пришлось внедрить еще одно правило. Мы стали работать по git flow.
Мы стали строго следовать ему и прониклись его идеологией. Работа стала легче. Легче стало сливать изменения в один бранч. Мы разделили билды на release, dev-stable, nightly. Все стали ответственнее относиться к тому, что они делают. Позже мы стали уделять внимание и коммит-месседжам. Привязывать их к тикетам в таск-трекере.
После первого релиза приложения, как это бывает, от юзеров стало поступать много жалоб. Приложение падает, это не работает, то, сё. Проблема была в том, что мы никак не могли получить подробной информации из жалобы. Нам нужно было либо воспроизвести баг силами QA, либо найти способ получить диагностическую информацию. QA может отловить только маленькую часть ошибок. На самые лютые баги всегда натыкаются ваши лояльные пользователи.
Все это потребовало внедрения системы аналитики и мониторинга, которые помогли нам диагностировать кучу проблем, о которых мы даже не подозревали. О многих ошибках юзеры даже не сообщали. В моем воображении они просто орали матом, а потом удаляли игру к чертям.
Мы не хотели сильно портить свою карму, поэтому стали проверять все ошибки, которые сыпятся с продакшен билдов. Никто не хочет стать сейлзом в следующей жизни, поэтому такие баги фиксились довольно быстро.
На границе
Вот так, я начал практиковать те вещи, которые раньше ненавидел. Презрение сменилось пониманием. Пришло и осознание, что проблема не в процессах, а в том как их трактуют. Проблема, как оказалось, глобальна. Люди, придумавшие Scrum, хотели сделать жизнь разработчиков лучше. Но за годы оно превратилось в то, что авторы назвали Dark Scrum.
Взяв простые и понятные правила, люди смогли извратить их до неузнаваемости. А потом стали жаловаться, что Scrum не работает.
В последнее время все говорят о DevOps. У термина куча определений. Но я знаю одно — DevOps должны делать жизнь людей проще. Нужно быть на границе между хаосом и порядком. Крайностей быть не должно. Свалиться в анархию и тонуть в сумбурности процессов — плохо. Ровно как и стремиться к тотальному контролю. Заставлять людей следовать процессам, которые только мешают.
Найти баланс сложно. Но чтобы его найти, нужно хотеть этого. У вас три пути:
- тихонько ныть, что все плохо, но молчать, надеясь что почему-то станет лучше
- взять все в свои руки и бороться за то, чтобы процессы помогали вам, а не мешали
- искать нового работодателя, надеясь что там все будет лучше
В любом случае, решать только вам.
DevOps — не только про разработку. Есть еще Operations, которые вне рамок данной статьи. Но там тоже нужен порядок.
В следующей статье мы поговорим о шагах к порядку. Многим они известны. Но я расскажу о нюансах, которые понял за последние годы.
Комментарии (51)
a4k
11.08.2017 15:42Они заставляли меня ходить на митинги полные пустых разговоров.
Не понимаю почему считается что разработчику ненужно участвовать в митингах.
Без них у него не будет представления о развитии проекта, какой должен быть конечный результат, не получиться по максимуму использовать опыт разработчиков, может с текущими проблемами кто то уже сталкивался раньше. Опять же это полезный опыт.
PoisonousJohn Автор
11.08.2017 15:49Я пришел к тому что в митингах полезно участвовать. И полезно понимать общие проблемы и вектор движения проекта. Приведенная цитата отражает мое отношение к этому в прошлом.
Но все же не все митинги бывают полезными. Проблема в том, что есть тенденция перетирать на митингах уже известные вещи. Мало новой инфорации. Еще одна проблема — односторонние митинги, когда ты не можешь сразу дать свой фидбек.a4k
11.08.2017 16:25+1Я понял что вы хотели сказать в статье.
Просто меня удивляет общая тенденция, да и практика тоже, что программистам митинги не нужны, потому я и выделил вашу строку.
Но все же не все митинги бывают полезными.
Это да. Но как по мне нельзя однозначно сказать что хуже — потерянное время на прослушивание уже известных вещей или отсутствие информации о развитии проекта.aquamakc
11.08.2017 16:43+1Просто меня удивляет общая тенденция, да и практика тоже, что программистам митинги не нужны
Вероятно ноги растут из излишнего фанатизма или некоторого ЧСВ программистов выше джунов. Такое наблюдал неоднократно:
«Я программист, я созидатель, я творю, я один понимаю как и решаю как оно должно быть, а все вокруг только мешаются».
Ну и митинги, в принципе бывают разные. Так-же лично присутствовал на совещании, которое собирал начальник производтвенного отдела, на которое были созваны начальники всех отделов, ведущие инженеры и генеральный. Совещание длилось полтора часа из которых почти половину времени обсуждали дефицит шайб.
Не совсем про разработку ПО, но аналогии можно провести.PoisonousJohn Автор
11.08.2017 17:46Вероятно ноги растут из излишнего фанатизма или некоторого ЧСВ программистов выше джуно
В моем понимании это связано больше с тенденцией делать только то, что предполагает роль (хотя это можно отнести к фанатизму). И это наблюдается не только у программеров.
Например, я работал с аниматором, которому было западло однотипно называть файлы анимаций, чтобы их было легко загрузить из кода. Он сказал «Я аниматор, я хочу анимировать, а не файлики переименовывать».
По аналогии и программеры поступают. «Я программист, хочу код писать, а не на митинги ходить и таски заводить».
AllexIn
12.08.2017 07:50+2Нет, проблем, аниматор. Мы снимаем с твоей зарплаты 5000 рублей и нанимаем школьника, который будет после тебя подчищать.
PoisonousJohn Автор
11.08.2017 17:53Просто меня удивляет общая тенденция, да и практика тоже, что программистам митинги не нужны, потому я и выделил вашу строку.
Общая тенденция ужасна. Тут я абсолютно согласен.
Это да. Но как по мне нельзя однозначно сказать что хуже — потерянное время на прослушивание уже известных вещей или отсутствие информации о развитии проекта.
Как правило, информацию о развитии проекта можно выбить из определенных людей :) А вот время вернуть сложно. В любом случае можно организовывать митинг в формате «сейчас новая инфа: бла-бла-бла. А теперь остаются те, кто не в курсе последних событий».a4k
11.08.2017 17:59Как правило, информацию о развитии проекта можно выбить из определенных людей :) А вот время вернуть сложно. В любом случае можно организовывать митинг в формате «сейчас новая инфа: бла-бла-бла. А теперь остаются те, кто не в курсе последних событий».
Еще бы знать заранее нужна тебе эта информация или нет.
А может наоборот не тебе что то полезное сообщат, а ты чью то глобальную проблему решишь.
marshinov
13.08.2017 12:12А ещё можно документировать что-то, вики там вести и/или правильно письменное общение в мессенджерах построить, но это уже "высшая лига":)
Idot
11.08.2017 16:41+1Чтобы народ на них с удовольствием ходил, митинг должен иметь кофе-брейк с бутербродами.
PoisonousJohn Автор
11.08.2017 17:38Это, конечно, мотивация, но люди будут ходить на митинг пожрать, а не послушать :)
avost
11.08.2017 23:09Они заставляли меня ходить на митинги полные пустых разговоров.
Не понимаю почему считается что разработчику ненужно участвовать в митингах.Разработчику не нужно ходить на митинги, полные пустых разговоров.
Без них у него не будет представления о развитии проекта, какой должен быть конечный результат, не получиться по максимуму использовать опыт разработчиков, может с текущими проблемами кто то уже сталкивался раньше
Для этого вполне сгодится пятиминутка раз в неделю. А лучше в две. А если для неё ещё и пиццу заказать :), то разработчики будут ходить туда с радостью, песнями, транспарантами и портретами вождей — ну, митинг же! :).
DrFdooch
11.08.2017 16:27+5было
Я просто хочу писать код.
сталоМы стали все фиксировать в трекере
не знаю, умышленно ли «я» сменилось на «мы», но этот прием подчеркивает интересный момент: когда разработчик не заинтересован ни в чем, кроме «писать код», он и не будет следовать ни best practice, ни процессу. и наоборот, заинтересованность в результате приводит к большей организованности.PoisonousJohn Автор
11.08.2017 16:31+1Да, интересное замечание. На самом деле был переход от «индивидуалиста» в «часть команды». Но оно как то за кадром осталось :)
izzholtik
12.08.2017 21:17+1Ключевая фраза всей статьи — «взять в свои руки». Всё остальное следует из неё.
BedwaRe
11.08.2017 16:40+1Спасибо за статью! Мне кажется, я понял что такое DevOps (до этого как-то сумбурно представлял). Мне кажется или эта статья подводящая к DevOps? В любом случае, с удовольствием, прочитаю продолжение.
eugenebb
11.08.2017 17:47+3Довелось поработать в нескольких командах которые практиковали Scrum и DevOps и через некоторое время начало закрадываться подозрение что за многими правильными словами скрывается нечто недосказанное и оно может быть более важно, чем сказаное. Как говорится, на фотографии торчат уши фотографа.
Перефразируя известный анекдот:
Есть стадо коров и пастух решает что делать выручка была побольше.
— Как сделать чтобы тратить меньше, а давали столько же молока?
— Больше доить и меньше кормить.
Пастух в данном случае это менеджмент
«Больше доить» — это значит больше и более разнообразных задач складывать на разработчиков («ты-ж-программист»)
«Меньше кормить» — иметь меньшую команду при тех же результатах.
Например, скрам-покер — известный факт что в большинстве случаев, программист over-optimistic при оценке задач, особенно при ограниченном колиестве информации и времени на оценку, а также психологическом давлении при публичном их вынесении, чтобы казаться лучше в глазах коллег и начальства.
В результате получается ситуация когда сроки назначенны и существует подсознательное давление что сам же их и назначил, обещал сделать, никто за язык не тянул и как результат впахивает гораздо больше чем мог бы в противном случае. И т.д. и т.п.
Ничего плохого не могу сказать из личного опыты, но в больших комнаниях по моим наблюдениям основными бенефециариями переходов на scrum и devops был непосредственный менеджемент и бюджет. Нет, не качество или конечный результат.
Не претендую на истину, но было бы интересно посмотреть на это под другим углом и послушать не «success», а «real-life» stories.
Ну а аппологеты процессов из числа команды — как говорят, лучшие надсмотрщики получаются из числа заключенных.PoisonousJohn Автор
11.08.2017 20:34Например, скрам-покер — известный факт что в большинстве случаев, программист over-optimistic при оценке задач, особенно при ограниченном колиестве информации и времени на оценку, а также психологическом давлении при публичном их вынесении, чтобы казаться лучше в глазах коллег и начальства.
Ну ты сам отвечаешь за это. Опять же, всегда можно сказать менеджеру, что ты ошибся. Правильный подход не наказывать за неправильную оценку, а вносить коррективы в оценку на будущее.
Часто сталкиваю с тем, что люди молчат о проблемах и дуются.
eugenebb
11.08.2017 21:12Я не про «дуется», а немного о другом.
О том что при принятии этих методологий существуют (или мне кажется что существуют) неафишируеммые последствия для разработчика (т.е. наемного работника), которые используют психологические приемы (специально или как приятный bonus для выгодополучателей его работы) чтобы он работал более интенсивно.
Мой вопрос в том что действительно ли это так и если да, то было ли это сделано осознанно.PoisonousJohn Автор
11.08.2017 22:46Просто посмотрите кто придумал эти методологии. http://agilemanifesto.org/authors.html
Лично мне кажется, что они изначально разрабатывались в помощь программистам. Но все их понимали по-своему и модифицировали, Эти же парни (авторы agile manifesto) были поражены, что появилась такая вещь, как Dark Scrum.
Возможно и мы сами их понимаем неправильно, боясь облажаться перед начальством.
Я работал в геймдеве и прекрасно понимаю о каких переработках идет речь. И я проходил через этот этап, когда я давал оценку, но не мог уложиться, работал на выходных. В конце концов я поговорил со своим менеджером и он меня отругал за это. Сказал, что это не правильно, и нужно корректировать оценку. Или переносить задачу на другой спринт.
Поэтому я могу сделать вывод, что это все зависит от начальства. Хотя и мы сами, если будем говорить о проблемах, можем повлиять на их точку зрения.
sumanai
13.08.2017 07:58+1В результате получается ситуация когда сроки назначенны и существует подсознательное давление что сам же их и назначил, обещал сделать, никто за язык не тянул и как результат впахивает гораздо больше чем мог бы в противном случае.
Чаще всего в итоге сроки всё равно срываются, так как переработки и спешка ни к чему хорошему не приводят. Так что по сути это идёт во вред менеджерам, как впрочем и программистам.
a4k
14.08.2017 12:57«Меньше кормить» — иметь меньшую команду при тех же результатах.
Мое видение меньше кормить — это набрать в проект junior менеджеров и программистов а ждать от них результата как от топовой команды сеньоров.
fivehouse
11.08.2017 19:01+1Вы забыли одну важную вещь написать. Люди как сверху вниз так и снизу вверх должны в команду быть отобраны такими, чтобы заботились друг о друге. И чтобы дух сотрудничества не затмевался духом соревнования, манипуляции и ненависти.
… но не надо управлять ради власти и управления. Ведь это должно помогать, а не напрягать.
Именно ТАК делают карьеру. Стремясь с помощью управления доказать прежде всего свою личную небходимость и с помощью игры на публику/(фальшивой)дружбы с руководством/интриг/манипуляций прити к власти/добиться личного роста. И да, либо личная карьера, либо хороший результат.PoisonousJohn Автор
11.08.2017 20:36+4Честно говоря я не встречал прямо таки нездоровой конкуренции между разработчиками. Командные игроки выгоднее для проекта, чем «звезды-одиночки».
KoCMoHaBT61
12.08.2017 09:45+100
Но это зависит от людей. Люди все разные, и в команду может свободно попасть человек-менеджер (термин не совсем правильный, но другого нет), который занимается личной карьерой. И всё, команда начинает играть по его правилам.
Но есть ещё один нюанс — когда в теме появляются деньги, то туда махом слетаются человеки-менеджеры, и вскоре контора будет состоять целиком из них.
evetrov
11.08.2017 20:38Все зависит от проекта и задач.
Если только начинается разработка и цена ошибки не так велика и тем более свой собственный проект — ни к чему формальности. Нужно быстро запуститься и посмотреть на результат.
Если это итерпрайз, котрый програмирует космические спутники на заказ — то тут крутится большое количество бабла и большая ответственность. Написание кода будет составлять 20% (условно) от всех усилий ибо будут вечные согласования, переписывания документации, десятки менеджеров и начальников.
Выбор остается за каждым — иметь очень не эффективную но крайне надежную разработку с кучей промежуточных звеньев, или иметь высокий кпд разработки, небольшой бюджет, но при этом самому быть разработчиком, что бы полностью понимать что происходит иначе легко свернуть не туда и виноватых потом не найти.
Я склоняюсь ко второму варианту ибо если ничего не понимаешь в разработке — нечего в разработку лезть и обставляться вокруг себя промежуточными звеньями с таким же уровнем непонимания.PoisonousJohn Автор
12.08.2017 14:35А как же банки? Сбербанк практикует Agile. Надежность для них крайне критична. Бабло, ответственность, все дела.
evetrov
12.08.2017 15:56+2Про аджайл в сбербанке знают только Греф и те кто вокруг него. В офисах от этого далеки :-)
Envek
13.08.2017 12:54Весь Сбербанк не практикует Agile и не будет его практиковать ещё года два-три-пять, как бы этого не хотел Греф. Agile требует перестроения мышления каждого сотрудника (больше того: культуры!), перестроения бизнес-процессов, перестроения организационной структуры. В организации такого масштаба это легко может растянуться на десятилетие — пока люди перевоспитаются (или уволятся), пока организацию перекроишь…
PoisonousJohn Автор
14.08.2017 08:54Конечно сложно сдвинуть что-то гигантское. Но положительный тренд уже прослеживается. Если банки смотрят в эту сторону, то значит Agile может отвечать всем требованиям качества/безопасности.
Кстати, еще вспомнил про Альфа-банк. Они не так давно писали про их Agile.
AllexIn
12.08.2017 07:53+1Проблема всех методик, в том что идиоты следуют им не разобравшись.
Как с традициями — в основе большинства традиций лежит некое событие, которое показало что надо делать так, а не иначе. Но потом про событие забылось, а «делай так» осталось.
Что мы имеем на выходе? Карго культ и всё. Который не работает, а только жрет ресурсы и мешает.
Если бы все методики применялись с пониманием — не было бы проблем. И отторжения у разработчиков тоже не было бы.PoisonousJohn Автор
12.08.2017 14:33+1Это можно сказать о всем где есть «философия». А методики — тоже философия.
amarao
12.08.2017 14:10+7Если менеджер не уважает программистов, которые пишут код, то не имеет значения, что внутри — ватерфалл, аджайл или телефонное право.
Если уважает — аналогично.
То есть проблема токсичных компаний состоит в том, что менеджер боится программистов (которые знают больше него), а программисты не чувствуют уважения (т.к. менеджер из страха вынужен использовать формальные метрики и игнорировать всё, что говорят программисты).
Мораль: если ты менеджер — слушай программистов и уважай то, что они говорят.
Если ты программист — объясняй, а если не слушают — ищи другую работу.
Если ты начальник над менеджером (начальник отдела/CTO/CEO/etc) — гони прочь менеджера, который не уважает программистов.PoisonousJohn Автор
12.08.2017 14:32+1Проблема отсутствия уважения существуют с двух сторон. Программисты тоже часто не уважают менеджеров просто за тот факт, что они менеджеры. Но в целом я согласен. В этом плане CTO во многом может на все влиять.
amarao
12.08.2017 15:39Да, разумеется. Менеджер представляет нетехнические ограничения (деньги, лицензии, пожелания клиента о странном и т.д.). Если программист игнорирует и не слушает такую информацию от менеджера, то это файл уже программиста. А основной причиной "не слушает" являетcя отсутствие уважения.
evetrov
12.08.2017 19:52Чем грамотнее менеджер в техническом плане тем больше понимания того что он делает и к чему это приведет и тем больше стоит его слушать разработчикам ибо разработчики не знают многих нюансов, когда сдвинуть на 1 пиксель иконку — это самая важная задача когда на продукт смотрит ген директор заказчика.
При малой грамотности наоборот менеджеру слушать разработчика надо.
Вообще это разные люди и нельзя требовать от одних полноценных знаний другого профиля. Нужно уметь перекладывать нужные задачи на плечи нужных людей — это крайне сложно, особенно разработчикам, которые в принципе все сами могут сделать.amarao
12.08.2017 20:48Если мы не говорим про тривиальные изменения, то менеджер не может знать что творится у разработчиков, даже если он сам из бывших разработчиков. Потому что очень часто возражения или предложения идут не от экзистенциального, а от очень практичного. Может быть, так, что для сдвига иконки на один пиксел надо переписать пол-приложения, потому что используемый фреймворк такого не умеет. И толковый менеджер должен в этой ситуации не «продавить», а спросить «а как мы можем сделать чтобы это было на один пиксел левее?». И, возможно, окажется, что проще перерисовать иконку за 5 минут, чем ломать архитектуру на протяжении двух месяцев.
Вот чтобы спросить — вот тут вот уважение и нужно. А у разработчиков должно быть уважение к менеджеру, чтобы не бояться говорить «можно вот так вот», даже если «вот так вот» грозит ужасом и авралами (распространённый метод саботажа «с низу» — не рассказывать про возможные решения, если решения грозят геморроем на местах).
Второй признак токсичности (кроме неуважения) — это когда разрабочик не может сказать «я этого не знаю». Когда все всё знают и все чёткие ровные, обычно образуется крайне резкая и жёсткая среда, при которой удачные технические ршения не выживают.PoisonousJohn Автор
14.08.2017 08:49И толковый менеджер должен в этой ситуации не «продавить», а спросить «а как мы можем сделать чтобы это было на один пиксел левее?»
Согласен. Но и толковый программист, если заинтересован в успехе проекта, должен предложить альтернативные решения.
Вообще, так как программист лучше всего осведомлен о текущем состоянии проекта, мне кажется, это обязанность программиста — предупреждать о возможных рисках/проблемах, и предлагать варианты решения. Менеджер же не должен пропускать это мимо ушей, должен принимать конкретные решения и дейтвовать.
reinvent
13.08.2017 09:15Слишком многое из того, что мы называем менеджментом, представляет собой помехи, которые мешают людям работать. Питер Друкер
PoisonousJohn Автор
14.08.2017 08:51+1Кстати, я заметил, что слишком много людей в менеджменте не имеют представления что это такое. Не имеют профильного образования. Не желают слушать и учиться. От того и помехи :(.
amarao
14.08.2017 12:12Профильное образование полезно, но не критично. А «не желают слушать» — это как раз отсутствие уважения.
u4ria
14.08.2017 15:00На сегодняшний день существует несчетное количество инструментов и методик. Все они, по-своему, отличаются и имеют свои достоинства и недостатки.
Зрелость тимлида\DevOp'а\менеджера определяется набором инструмента в его арсенале. Умение определить задачи команды и выбрать подходящий инструмент, технику или концепсию.
Недостаточно просто прочитать очередную статью о новой модной методологии и заставить свою комманду следовать ей.
Задача инструмента — облегчать работу и если он подобран правильно, он незаметен. Он просто помогает тебе делать своё дело, он — как еще один орган твоего тела, специально обученый выполнять определенную задачу. Ты просто рефлексорно им пользуешься.
Бывают случаи, в которых, вроде бы подходящий на первый взгляд инструмент, должен работать, но КПД низкий. Причин на это может быть огромное количество, и не всегда они видны невооруженным взглядом. Особенности сферы деятельности, кол-во сотрудников в команде, их взаимотношения, георасположение, отсутвие базового понимания назначения инструмента, банальное отсутсвие мотивации или просто желание быть бунтарём и отвергать любые нововведения. Последнее особенно проблематично, если человек достаточно харизматичен и способен склонить к этому остальных участников команды.
Задача менеджемнта (человек в любой должности, ответственный за внедрение новых инструментов) вовремя обнаружить проблемы в интеграции тех или иных техник\инструментов, установить причину и предпринять необходимые меры. Не боятся пробовать новые инструменты и избавляться от существующих, несмотря насколько они хайповые на данный момент.
Если, все условия выполнены, команда будет тратить бОльшую часть времения для усовершенствования продукта\сервиса.
ganqqwerty
14.08.2017 18:39я регулярно сталкиваюсь с командами, которые следуют всем церемониям скрама, начисто забывая про его дух. Например, есть все положенные роли и митинги, но процесс не итеративный и клиент не то что не присутствует, а даже не определен. Особенно ярко это проявляется в госсекторе и науке где рынок не карает тебя за ошибки
Aries_ua
В таких случаях я всегда говорю — без фанатизма. Один знакомый тимлид как то за чашкой чая рассказал, что он проанализировал, что стендап митинги длятся долго. И он принял решение стоять с секундомером, давая каждому минуту на доклад.
Как так можно напрягать команду? Это же постоянное напряжение. Зачем, что бы выиграть 5 минут?
У мебя в команде я наоборот веду политику, спокойствия, дружеского отношения и доверия. И мы очень редко выходим за 10 — 15 минут. Но зато я знаю, что все вопросы, замечания и предложения будут озвучены. Люди довольны, всем комфортно.
Поэтому, все эти штуки придумали нельзя, но не надо управлять ради власти и управления. Ведь это должно помогать, а не напрягать.
PoisonousJohn Автор
Да, согласен! Все хорошо в меру.
В команде очень важно общаться. Если вы чувствуете, что что-то напрягает или процесс просто не работает, то нужно об этом говорить. А в обязанности тим лида, в том числе, входит и необходимость слушать своих подопечных.
JediPhilosopher
А я наоборот соглашусь с «знакомым тимлидом». У нас митинги тоже затягиваются и это реально бесит. Причем по идее сказать пару слов о сделанном и о планах — на это много времени не надо, минуты вполне хватает при ежедневных собраниях. А вот если кто-то начинает излишние подробности излагать (ну есть такие люди которые не умеют кратко говорить), или спорить друг с другом — вот так это все на час и затягивается. А остальные сидят и скучают.
Все долгие моменты можно обсудить либо лично, либо на каком-нибудь отдельном собрании, где будут только те кому это интересно. А общие собрания должны быть максимально короткие.
LbISS
Поддержу. Основная проблема — формат митинга. Должен быть точная повестка и формат изложения для каждого участника, тогда затягиваться сильно не будет.
Пример — ретроспектива на 20 человек раз в неделю. Если проводить её в свободном формате — то каждый будет рассказывать про какую-то конкретику по своим задачам, в целом скорее всего не интересную остальным или интересную, но не с такими подробностями. Явно не меньше 5 минут, а в среднем минут 7-8. 20 человек * 8 минут = прощайте два с половиной часа.
Изначально так и было. Долго, малоэффективно. Меняем формат — каждый человек к ретроспективе должен подготовиться и ответить на два вопроса: что в общем процессе работы команды на этом спринте было самым положительным моментом и что было самым отрицательным. Все, по-очереди, отвечаем на эти вопросы — фиксируем на доске.
Решаем несколько проблем — 1) отсекаем неважное, все могут сказать только одну вещь, думают и выкладывают самое важное. 2) готовятся заранее, нет моментов когда один человек думает — 20 ждут. 3) каждый обязательно высказывается и всё фиксируется у всех перед глазами, тезисы четкие и не требуют доработки. 4) обсуждаем общий процесс, а не конкретные проблемы.
Занимает от 30 секунд до полутора минут на человека. Без обсуждений, чисто постановка проблемы. Итого 15-25 минут. После чего когда все высказались — на доске у всех перед глазами есть "проблематика", инициируем обсуждение и решение по проблемам, подмечаем сильные моменты в работе. В этот момент, по каждой проблеме команда думает вместе, никто не "засыпает" выслушивая неинтересные чужие проблемы, предлагаются решения, фиксируются. Если обсуждение занимает больше 5 минут — ставится задача "обсудить отдельно заинтересованным", к следующей ретроспективе результаты. Это занимает еще 30-40 минут.
Итого: вместо 2,5-3 часов — час или час с копейками, все проблемы зафиксированы и видны всем, долгие обсуждения вынесены в отдельные группы, отсечено всё неважное и не относящееся к общей работе команды.
marshinov
Причины у затяжных стендапов может быть две: 1) команда элементарно не готовится (за 5-10 минут до мита нужно открыть трекер и освежить в памяти что я делал вчера, что буду сегодня и какие проблемы), 2) начинается обсуждение проблемы в рамках стендапа. Если проблема большая, сначала завершаем со стендапом, затем оставляем на обсуждение только заинтересованных. При соблюдении этих простых правил за 15 минут вывалиться можно только если в команде больше семи человек, а это уже сигнал, что лучше организовать две команды из трёх-четырёх.