Нам нужно поговорить…
Иногда инженеры теряют интерес к проектам, задачам и к компании — мотивация падает, а с ней и производительность. В итоге сотрудники выгорают и/или увольняются. Для этого много причин, но самая распространенная — отсутствие внимания к успехам и проблемам инженеров.
В ЦФТ эту проблему решили регулярные встречи с инженерами один на один. Встречи помогают: вовремя выявить проблемы в работе, профессионально развиваться, повышать мотивацию и находить новые смыслы. О том, как готовиться ко встречам, какие вопросы задавать и как регулярно их проводить, расскажет Михаил Емельянов. Теперь вы будете знать, что делать, если инженер сказал: «Нам нужно поговорить…»Михаил Емельянов — Head of Android Department в ЦФТ. В IT-разработке 12 лет, с Android — 10, из которых 2 года руководит командой Android-разработки в ЦФТ. Разрабатывал проект мультимедиа, различные проекты в финтехе и запускал стартапы.
Демо-день на удалёнке. Уходим в онлайн
Привет!
Удалёнка это хорошо, но демо-дни никто не отменял. И если с общими коммуникациями команд еще можно как-то справиться с помощью того же Zoom / Microsoft Teams / прочего подобного софта, то с демо-днями ситуация обстоит немного сложнее. Во-первых, демо-день обычно ощутимо длинее стандартной планёрки или совещания, и занимал у нас в среднем часов 5. Во-вторых, у демо-дней есть ряд особенностей в плане организации, очередности выступления команд и прочего. Ну да вы знаете.
Так вот. Это был первый демо-день, который мы решили провести в онлайне, но в привычном для всех составе. В итоге собрали 250 человек, включая спикеров из дружественных компаний (A1, X5 Retail Group, Альфа-Капитал и других).
Как всё прошло, о чём говорили, зачем в демо-днях геймификация и пара опросов — под катом.
Внедрение. Первые шаги agile
Изменения решил начать с ввода ретроспектив. Дождавшись очередного послерелизного понедельника собрал всю команду и предложил встречаться после сдачи релиза для обсуждения — насколько эффективно мы отработали по каждой из целей и как можно было бы ещё увеличить эффективность и приблизиться к Видению.
Там же предложил совместно обсуждать реализацию заданий, аргументируя тем, что при наличии нескольких мнений можно находить лучшее решение. К тому же, при подобных обсуждениях, должна повыситься видимость внутренних процессов конфигурации для разработчиков, сопровождающих смежные подсистемы. Да и совместное обсуждение интересующей всех темы — это лучший тимбилдинг. От этого простого действия видны одни лишь плюсы. Минус только один — чуть большие затраты времени, но при всех описанных плюсах — эта издержка ничтожна.
Весь следующий релиз мы работали по новому. Теперь, когда приходило задание, я его не диспетчировал на разработчика, а ставил всех разработчиков в наблюдатели, что бы они могли ознакомиться с заданием, а на следующее утро приглашал для обсуждения. И сработало. Обсуждения были жаркими, каждый пытался блеснуть креативностью и в результате, после просева предложений по реализации задания или после смешения нескольких идей в одну, рождались очень интересные решения, по факту — лучшие, исходя из совместного интеллектуального опыта команды. Как руководитель разработки я стал спокоен за качество реализуемого функционала.
Встречи для обсуждения функционала подтолкнула меня к мысли, а почему бы не встречаться ежедневно для обсуждения не только заданий, но так же и своими результатами разработки (то есть я дорос до стендапов, предлагаемых в agile). Это и было мною предложено на очередной ретроспективе и так появились ежедневные утренние встречи (что бы не пугать иноземной терминологией, они у нас назывались «планерки»).
На каждой ретроспективе (кхе, на «подведении итогов») искались слабые направления развития (то есть Цели), по которым мы меньше всего продвинулись за релиз и обсуждались способы наверстать отставание, например,
- Совершенствование цели «Производство» (качество выполнения разработки) осуществляется за счет оптимизации функционала, рефакторинга кода, визуализации бизнес-процессов, обучения разработчиков и т.д.
- Совершенствование цели «Администрирование» осуществляется за счет поиска и устранения простоев заданий или изменения маршрута задания, с целью повышения эффективности; так же здесь решались хозяйственные вопросы.
- Совершенствование цели «Интеграция» (взаимодействие членов команды) осуществляется за счет чтения лекций по командному поведению, по мотивам книг [], [].
- Совершенствование цели «Предпринимательство» (планы по развитию и совершенствованию команды) осуществляется за счет проведения ретроспектив и обсуждения там вопросов улучшения любой из целей выше, введение правил или норм поведения или обсуждение конфликтных ситуаций, возникших в команде, изменение целей.
Таким образом был организован agile, с ориентиром на стратегический план, то есть на Миссию, Видение, Цели. Ох, про Ценности забыл. Ценности — это перечень правил поведения в команде, то есть чем мы руководствуется при взаимодействиях. Например, указали в Ценностях «Сотрудничество» и если кто-то начинает «тянуть одеяло на себя», то будет способ его одернуть, напомнив про Ценности команды. Если задали «Честность», то за любой обман можно будет спросить, опираясь на Ценности команды. Ценности так же разрабатываются совместно всеми членами команды.
Без «Hello, world!» и в IT?
Петрович был старым опытным CTO — он ещё помнил перфокарты, а количество языков программирования, которые он знал, было примерно равным числу языков, которые канули в Лету естественного отбора в IT-среде и благополучно затерялись в долгосрочной памяти Петровича.
И потому на пятом этаже, где в основном сидели разработчики, он сразу заметил странную личность. Одет парень был слишком уж аккуратно. Бороды лесоруба не наблюдалось. Ни футболки с принтом, который что-то должен означать и что понимает только сам владелец. В общем, совсем не админ или Devops-инженер. Глаза нормальные, не красные, чёрных кругов под ними не наблюдается, ни татуровок, ни пирсинга, даже ноута подмышкой нет, а значит — не разработчик.
Петрович аккуратно загнал его в угол и спросил:
— Тебе как зовут, Вася? — Серёжа. — Скажи, Серёжа, что такое «99 бутылок пива» и числа Фибоначчи? — Что? — «Hello, world» — это что? — Здравствуй, мир! — просиял Серёжа-Вася. — Ясно, — сказал Петрович и потащил Серёжу к безопаснику.
Там в кабинете он торжественно вручил коллеге дичь.
— Вот. Шпиона поймал. Производственный шпионаж, как он есть. На пятом этаже бродил, в программировании разбирается, как коза в стиле и этикете.
Безопасник устало махнул рукой:
— Петрович, отпусти его. Наш это. Айтишник. Scrum-мастером зовётся. Уже неделю работает. — Один спринт, — пискнул Серёжа.
Петрович тоскливо задумался о временах перфокарт.
Шаг 1. Подготовка участников
Когда проводить ретроспективу и какие вопросы задавать?
Например, мы хотим узнать результаты прошедшего квартала, первого в году. Логично, что готовиться к ретроспективе стоит в конце этого же первого квартала, пока свежи все мысли, эмоции и переживания.
Курс «Машинное обучение и управление проектами в IT для преподавателей»
Старт 1 июня, 11 недель, онлайн, беcплатно
tproger.ru
События и курсы на tproger.ru
Следующий момент, требующий внимания до встречи, — это список вопросов. Это могут быть стандартные «что мы сделали хорошо?» и «что мы сделали плохо?» или другие насущные вопросы, которые могут прийти в голову. Например, можно узнать, какая в команде атмосфера. Не исключено, что кто-то ответит «у нас всё круто, твердая пятёрка», а кто-то из этой же команды поставит троечку с натяжкой. Вот вам и повод хорошенько всё обсудить.
Ещё несколько примеров вопросов
Стандартным для нашей команды является вопрос «кто вам помогает в работе?». Вопрос на первый взгляд странный, но он способствует сплочению коллектива, выявлению наиболее инициативных членов команды и их моральной мотивации. Вот только задавая такой вопрос, будьте готовы, что официальный лидер не обязательно будет таковым в глазах подчинённых.
Можно также узнать противоположное мнение: «кто вам мешает в работе?». Тут тоже стоит ожидать разброса в ответах. Это может быть чересчур общительный коллега или непосредственный начальник, который то и дело просит какие-то отчёты, или угрюмый представитель компании-партнёра, с которым, хотите вы того или нет, а надо общаться.
Точно не стоит спрашивать «кто виноват?». Как бы вам ни хотелось получить ответ на этот вопрос, задавая его вот так напрямую, вразумительного ответа вы не получите. Чего вы точно добьётесь, так это перекладывания вины и ответственности, нездоровую атмосферу в команде и тяжёлый осадок обид. Задавая вопросы, разбирая ответы и проводя саму встречу, стоит настроить себя на то, что все выложились по максимуму и сделали всё, что от них могло зависеть.
Превентивные вопросы
Я рекомендую использовать ещё один небольшой лайфхак при подготовке к встрече. Чтобы в процессе ретроспективы точно придерживаться намеченного плана, не забыть ни одного вопроса и услышать всех, я задаю некоторые вопросы заранее, до самой встречи с помощью гугл-формы. На заполнение даю примерно два дня, чтобы точно нашлось время, а дедлайн ставлю минимум за полдня до начала события, чтобы успеть прочесть ответы.
Какой от этого профит, спросите вы, если всё равно все соберутся и будут обсуждать то же самое? Не все люди умеют или любят разговаривать с другими. Не все могут сразу сформулировать свою проблему: будут рассказывать длинную предысторию, где в самом конце, возможно, промелькнёт то, что человек хотел сказать. Может случиться и так, что это будет попытка найти фантомную проблему там, где её нет, с аргументацией: «не знаю, что точно, но всё как-то не так». Время — деньги, поэтому я даю шанс людям предварительно высказать все мысли и эмоции на бумаге, сэкономив команде силы на ретроспективе.
Почему планирование лечения — это необходимость для пациента и клиники
Потому что пациенты лечатся, пока у них болит. Стоит перестать болеть — и пациенты пропадают. Если речь про терапевтическое лечение, то можно обойтись без плана: пациент остро чувствует мотивацию. А вот как только мы говорим про профилактику, какие-то сложные процедуры или комплексное лечение — начинаются проблемы и у врачей, и у пациентов.
Очень-очень мало врачей способны показать целевое состояние больного и комплекс мер, которые из «было» ведут к этому «стало». Стандартный интерфейс лечения такой: ты, больной, приходи ко мне, великому врачу, до тех пор, пока я не скажу, что хватит. Я лучше знаю, что тебе делать и как
А это важно. Потому что, по логике, нужно описать состояние пациента на диагностике, показать ему все проблемы, показать точный план лечения для каждой, собрать это в комплексный план и объяснить ему
Так он поймёт, что именно происходит, сколько времени это займёт, сколько денег нужно и из чего конкретно складывается смета.
Мы остро почувствовали это в стоматологии уже при переходе от экономсегмента к среднему и сразу же стали делать соответствующие модули в ПО. Как выяснилось позже, планы лечения помогли решить ещё целый ряд проблем — от воровства внутри клиники до разделения ролей врача и администратора-консультанта.
Но давайте начнём с того, что каждый врач лечил пациентов творчески-неповторимо, на вдохновении и интуиции.
Как сделать курс по Аджайл на принципах Аджайл
Во вторник, 28 апреля мы провели первый ознакомительный вебинар Вечерней школы Слёрма по Аджайл. Зарегистрировалось на курс 1700 человек. Курс открытый и полностью бесплатный — мы приняли решение помочь управленцам, владельцам бизнеса и скрам-мастерам в это непростое время.
Мы сделали то, что никогда ещё не пробовали. У нас получилось создать курс за 1 неделю — придумать идею, проверить гипотезу, найти ценность для участников, подготовить программу, улучшить её несколько раз, выбрать аппаратуру и инструменты для удобной трансляции и тесного взаимодействия с участниками. Всё же Аджайл в первую очередь — это командная работа, даже если все сидят в самоизоляции.
Мы поставили себе цель — будет онлайн, как в офлайне. Диалог со спикерами, разговоры в «зале», обмен опытом, юмор для разрядки рабочей атмсоферы, взаимопомощь, драйв командной работы.
На первом вебинаре мы разбирали преимущества Аджайл во время кризиса. Преподаватели показали на примерах российских и зарубежных компаний, как Аджайл может помочь в ситуации неопределённости и экономической рецессии — и поделились практическим опытом и советами.
Строим ролевую модель управления доступом. Часть вторая, «строительная»
Пост, который вы сейчас читаете, – продолжение статьи о том, как правильно выстроить в крупной компании ролевую модель управления доступом пользователей к различным системам. Напомним: построение ролевой модели – это скорее процесс, чем результат, и первую часть нашей дилогии мы посвятили подготовке к «строительству». В ней мы рассказали, как создать функциональную модель каждого подразделения и должности, провести аудит ИТ-систем и расставить их по приоритетам, создать бизнес-ориентированное описание прав пользователей и о других важных подготовительных шагах. Сегодня же поговорим о способах построения ролевой модели, ролевых матрицах, чем здесь поможет внедрение автоматизированных систем управления доступом (IdM/IGA), и что вы получите на выходе.
Шаг 3. Проведение ретроспективы
Все собрались в назначенном месте или в скайп-чате. Теперь нужно соблюсти небольшой регламент и озвучить, по какому поводу собрались. Лучше ещё разок напомнить, что сегодня мы обсуждаем проблемы, возникшие в первом квартале текущего года. Это поможет участникам ретроспективы настроиться на нужный диапазон воспоминаний и откинуть то, что было до или после.
Порядок выступающих
Всё зависит от масштабности вашего мероприятия. Если вы небольшая команда, которая работает над одним общим проектом, то порядок не важен. Можно по мере поступления ответов, в алфавитном порядке и тому подобное. Если у вас несколько проектов, то собирайте людей в проектные группы, а порядок распределяйте по принципу выше.
Итак, все организационные вопросы решены. Давайте начнём ретроспективу.
Как это обычно происходит?
Ведущий опирается на выписанные им выдержки из ответов. Он озвучивает суть проблемы и задаёт вопрос тому, кто её описал.
Что спрашивать?
Если проблема была изложена слишком коротко, можно попросить рассказать подробнее. Если суть ясна, то можно предложить человеку рассказать, почему, на его взгляд, так случилось и можем ли мы как-то повлиять на эти факторы. Если человек выражает реализуемую идею, то стоит её зафиксировать. Даже если кажется, что другого варианта просто не существует, стоит спросить мнение остальной команды. Если у кого-то есть свежая мысль, её обязательно надо обдумать всем коллективом.
Бытует мнение, что решить чужую проблему гораздо проще, чем свою. Потому что ваши проблемы на поверку могут показаться коллеге решаемыми, стоит только использовать другой, не совсем стандартный для вас подход. Свои же проблемы на то и свои, мы с ними живем, мы о них думаем, мы с ними сроднились и не хотим их отпускать.
Как фиксировать информацию?
Когда участники высказывают идеи, ведущий фиксирует их в колонке «Plan». Если вариантов по решению конкретной проблемы больше нет, можно выбирать наиболее оптимальный вариант, на взгляд всей команды.
Кстати, после того, как вы определились, выбранный вариант тоже нужно зафиксировать. Для этого нам понадобится третий лист ретроспективы — «Регламентируем предложения» («Наши планы», «Сделай так», «Итоги» и тому подобное). Именно сюда выносим согласованные предложения, назначаем ответственного и ставим контрольный срок исполнения.
Не забудьте, что сроки по каждому пункту надо обсудить с ответственным. Даже если речь идёт о разговоре с дизайнером и это дело пяти минут, всё равно ставьте срок. Это позволит не забыть о порученной задаче. Конечно, одной записи на листочке может быть мало. Ведь все люди что-то забывают, но к этому мы ещё вернёмся.
Остались вопросы?
Когда проблемы закончились, и по каждой есть план действий, обязательно спросите: «Кто хотел бы высказаться о чём-то ещё»? Возможно, у человека была мысль, но его перебили, и мысль так и осталась мыслью.
Убедившись, что мнения высказаны, мнений больше нет, приглашайте всех посмотреть тот самый третий лист, который вы так усердно заполняли. Его должны прочесть все и либо устно подтвердить то, что увидели своё задание и срок выполнения, либо отметиться в документе или скайп-чате. Кроме того, ведущему ретроспективы тоже свойственно ошибаться, поэтому это ещё и командная проверка написанного.
На этом ретроспективу можно считать состоявшейся и расходиться. Не забудьте поблагодарить всех коллег, принимавших участие. Но не стоит ставить на этом точку. Ведь только сейчас и начинается решение существующих проблем и продвижение на пути к успеху.
Сопровождение. Текучка по agile
… Теперь рабочий день начинался с обсуждения незавершенки, новых заданий, планов на день. Когда долгосрочных заданий стало очень много, была заведена канбан-доска и обсуждение происходило по всем работам, которые имели состояние «В работе». Так же на доске можно было посмотреть, что у нас «В плане» и «На анализе». После выпуска релиза мы обсуждали способы совершенствования работы нашей команды.
Таким образом, из скучной рабочей группы, где каждый в одиночку развивал свой кусок конфигурации, мы развились в команду, со своими правилами, нормами, культурой и ценностями.
Можно развиваться и дальше — по целям разработать KPI и оценивать недоработки команды уже в количественных показателях, но мне кажется, что для небольшой команды это будет перебор.
Скрам умер. Да здравствует канбан
Перевод
Я пользовался методом управления проектами Scrum (скрам) с самого начала карьеры. Я изучал скрам в колледже. Тогда он считался лучшим методом управления разработкой программного обеспечения. Когда я начал работать, мне нравилось всё, что имеет отношение к скраму: ежедневные встречи, планирование, ретроспективные совещания, спринты и так далее. В конце концов, я пользовался на практике тем, чему меня учили.
Но через несколько лет я начал кое-что замечать: в последние дни спринта все бросаются доделывать всё то, чем занимались в предыдущие две недели, стремясь избежать переноса задач на будущее
Часто те, кто так поступали, брали на себя ненужный риск.
Почему? Разве какие-то задачи не могут подождать до следующей недели? Так ли важно доделать абсолютно всё до выходных? Нет, не так уж это и важно. А всё это происходит из-за того, что «Переносы задач — это плохо».
Я все еще считаю, что проводить ретроспективы нужно
Я не говорю, что всем нужно прекратить проводить ретроспективы. Они полезны и имеют свое предназначение даже в организации, которая пытается непрерывно совершенствоваться. И они могут дать возможность подумать о том, как преуспевает команда, пересмотреть показатели, сформулировать эксперименты и выявить неявные давние проблемы, которые никогда не проявлялись, потому что никогда не были острой и неотложной проблемой.
Они также являются важным первым шагом на трудном пути к непрерывному совершенствованию. И большинство компаний в мире не сделали даже этот первый шаг.
Но давайте не будем обманывать себя
Ретроспективы могут быть полезными и хорошим первым шагом, но они не являются непрерывным улучшением и не являются кайдзен. Всем, кто не понимает, откуда пришли эти идеи, я бы порекомендовал прочесть «Тойота Ката. Лидерство, менеджмент и развитие сотрудников для достижения выдающихся результатов» Майка Ротера.
P.S.: Через неделю мы представим взгляд на ретроспективу с точки зрения ТОС. Ретроспектива может быть результативной!
Как мы первыми в мире роботизируем кормоуборочные комбайны
Недавно мой коллега рассказал как мы роботизируем зерноуборочные комбайны и чему научились за этот сезон.
Начинается уборка кормовых культур и мы активно осваиваем кормоуборочную технику.
Кормоуборочный комбайн – технически более сложная и мощная машина. В связке с ним идут сразу несколько транспортных средств для сбора урожая (трактора с прицепом, грузовики, силосовозы). К работе на такой технике допускаются только опытные механизаторы, у которых за спиной несколько лет работы.
Работа на комбайне во время уборки кормовой кукурузы похожа на езду в машине в густом тумане, только вместо тумана на протяжении всего пути высокая зеленая стена из растений, из которой может выскочить кабан, столб или человек. Перемолов человека (история есть в моей прошлой статье), комбайнеры седеют и больше не могут работать. Кроме этого, в этом «зеленом тумане» надо суметь не врезаться в рядом едущий силосовоз, следить за точностью загрузки силоса с хоботом длиной до 7 метров, из которого вылетает по 50-60 кг силоса в секунду, и равномерно заполнять фургон, чтобы он не гонял полупустым туда сюда.
Фактически один комбайнёр работает за троих, следит за процессом уборки кукурузы (одно рабочее место), ведёт технику (второе рабочее место), загружает силосовоз (третье рабочее место). В итоге что-то страдает. Если плохо вести, можно сломать дорогую технику (минимальная цена кормоуборочного комбайна 16 млн рублей, есть модели и по 50 миллионов), поэтому обычно ухудшается качество уборки и загрузки.
Большую часть работы мы автоматизируем, сейчас расскажу какие сложности мы преодолеваем и что делаем.
IV Применение гибких методологий
5. Как не надо использовать Agile
- Лидером в моем антирейтинге является ситуация, когда Agile, а вернее некоторые ее принципы, пытаются использовать не для достижения каких-то конкретных целей, которые они позволяют обеспечить, а просто #ПОТОМУШТО. Потому, что это тренд, это у всех на устах. Например, кто-то поделился на ИТ тусовке положительными отзывами, немного эфемерными и даже заносчивыми, но пошла молва, появился антураж. И вот уже назвавшиеся последователями Agile, ощущают в общении с остальными — принадлежность к некому элитарному клубу. Всему этому способствует кажущаяся простота методологии и туманные очертания ее границ. Внедрения по такому принципу происходит бездумно и формально. Люди, формально и беспринципно внедряют принципы, призванные снизить формализм.
Вот например, один из совсем свежих случаев. В одной фирме проводя Ретроспективы, запретили их посещение тимлидами. Вот такая фишка. Неожиданно. Первая мысль: ну может быть они и правы, чтобы типа не было давления авторитетов на коллектив при обсуждении проблем и т.п. Но тимлиды обижаются, они в недоумении и хотят разобраться. Я попытался переубедить, что мол может так то оно и лучше, главное, чтобы Вам по итогу выдали список пожеланий, с перечнем, что надо менять, что улучшать и т.п. И вот тут-то и открылась страшная тайна. А ни каких итогов и пожеланий к улучшению процессов в результате этих посиделок не возникает. Господа ИТ_шники, а зачем же тогда такая ретроспектива? Просто похвалить друг друга и поднять командный дух? Сказали А, говорите и Б. Ведь основная цель этого процесса методологии и заключается в том, что: «Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы». - Вторая в моем рейтинге ситуация, когда команды решают сэкономить на подготовке требований в проектах со сложными поведенческими или логическими алгоритмами. То есть, когда пользовательская история является лишь небольшой вершиной айсберга проблемы, а его основная часть не видна и для реализации требует детального, тщательного анализа и проектирования. Что при этом происходит?
Перед началом работ ни заказчик ни разработчики даже приблизительно не понимаю, тот объем работ, который им необходимо проделать. А соответственно: либо заказчик будет платить, платить и платить, каждый раз, когда ему будут растолковывать, что все оказалось горазда сложнее и теперь еще конца и края работам не видно. И ведь бросить будет жалко и постепенно начнет гложить суровое понимание, что этот «золотой» продукт уже никогда не окупится. Либо разработчики, подрядившись выполнить работы за определенную сумму/время, будут за свой счет (бесплатно) доделывать и переделывать продукт, пока у заказчика не иссякнет фантазия, или он не сжалится над жертвами гибкого подхода. - Почетное третье место занимает ситуация, когда в большом многофункциональном проекте (а вдруг еще и интеграционном) команда решает сэкономить на проработке архитектуры решения и начинает короткими итерациями реализовывать отдельные пользовательские истории. С большой долей вероятности случится так, что через 3-5 итераций, при попытке создать новый функционал, окажется, что надо переделывать весь предыдущий, так как не учли фундаментальные принципы, на которых этот функционал должен был базироваться. Еще хуже, если уже после 10_ой итерации обнаружится, что выбранные технологии не позволяют удовлетворить все потребности заказчика и надо начинать все сначала. Возможно, поменяв команду.
- Не попала в тройку ситуация, в которой резкий и неимоверно гибкий стратап врывается на просторы вялого сегмента рынка. Стартап, он на то и стратап, что в нем нет ни каких устоев, скрепов, привязанностей, а вместе с тем устойчивости и стабильности. А проще говоря, нет почти никакой документации, коллектив не слажен и часто меняется. Рынок буквально рвет команду, требуя все новых и новых решений в застолбленной области, а все последующие проекты просто разваливаются на глазах. Чаще всего, все объясняется тем, что в команде нет понимания процессов промышленного производства ПО, организации поставки и поддержки продукта.
Загрузка...
