Agaltsov Anton | IT-блог TGM
680 subscribers
215 links
IT телеграмм блог, который должен пригодиться бизнес-аналитикам, проджект и продукт менеджерам, а самое главное Тимлидам в разработке.
Download Telegram
​​Эффект наблюдателя

Чтобы узнать, посолен ли борщ, достаточно опустить в него два электрода, а затем пустить по ним ток. Если появится запах хлора — значит, борщ уже посолен.

В физике есть такое понятие как «эффект наблюдателя»: если над системой ведется наблюдение, то оно вносит изменение в ее поведение. Очень интересно этот эффект проявляется в организации работы команд разработчиков. Как только мы начинаем считать любые метрики, мы вносим изменения в поведения команды и отдельных ее членов.

Все знают понятие «индусский код»: как только разработчикам начинают платить за количество написанный строчек кода, они и начинают писать больше кода, зачастую бессмысленного, забывают про рефакторинг, его делать становиться невыгодно и так далее. Таким образом, наше начинание по замеру производительности оборачивается против нас.

Можно попробовать сократить количество дефектов в нашем продукте, для чего считать, сколько багов сделал каждый разработчик. Лучших разработчиков будем награждать бонусами, а к худшим разработчикам — применять санкции. Все просто и прозрачно. Но на деле получиться по другому: разработчики будут спорить по каждому багу с тестировщиками, появится боязнь и желание избегать рисков, как результат отсутствие инициативы и нежелание делать поставленные задачи («Меньше задач, меньше багов»).

Давайте подойдем с другой стороны и будем считать, сколько багов находят тестировщики. В этой ситуации также появятся косвенные эффекты, ведь каждый тестировщик будет расценивать малейшее отклонение как дефект.

Вывод из приведенных выше примеров простой, при введении метрик, необходимо руководствоваться, прежде всего, принципом «Не навреди».

Как быть?

Проанализируйте, как измерения могут повлиять на поведение команды и отдельных ее членов. Причем анализ надо проводить в первую очередь по поводу не очевидных аспектов, которые могут проявиться не сразу. Подумайте, какие метрики могут послужить основой для обсуждений, например, на ретроспективах, если вы используете Scrum. Может быть ваши измерения в действительности никому не нужны и вы меряете, просто, потому что можете мерить?

Посчитайте, сколько времени у вас уходит на сбор информации по метрикам. Очень вероятно, что этот процесс можно автоматизировать, в особенности, если мы говорим о метриках кода, метриках качества и тому подобных.

При внедрение метрик, как и любых других инноваций, очень неплохо использовать цикл Деминга: Plan-Do-Check-Act, чтобы у вас была возможность получить фидбек от команды и внести изменения в случае необходимости.
​​Матрица доверия и прозрачности

Матрица показывает, что происходит с отношениями заказчика и подрядчика.

A. Низкое доверие & Низкая прозрачность. Предположим, начинается новый проект, который вы искренне желаете успешно сделать, тем самым нанеся непоправимую пользу заказчику. Но заказчик вас пока не знает, и работать вы только начали — прошла пара дней. Где находятся ваши отношения с заказчиком? Скорее всего, в квадрате A.

Да, заказчик вас уже выбрал, то есть проявил какое-то минимальное доверие. Поэтому ваши отношения не на нижней границе квадрата A.

При всем этом каким-то образом хочется подняться в зону высокого доверия.

B. Низкое доверие & Высокая прозрачность. Именно нахождение в квадрате B при условии того, что есть не только прозрачность, но и РЕЗУЛЬТАТ, поднимает доверие. Человек видит, что его деньги, время, репутация, карьера используются вами на дело. И это автоматически повышает уровень доверия и передвигает ваши отношения в квадрат: С.

C. Высокое доверие & Высокая прозрачность. Со временем из квадрата C вы можете перебраться в D, если заказчик увидит, что наведение прозрачности требует значительных ресурсов.

D. Высокое доверие & Низкая прозрачность. Нахождение в этом квадрате довольно неустойчиво. Происходит моментальное падение в квадрат A в случае:
- Любой мало-мальски серьезной проблемы на проекте
- Смены человека со стороны заказчика

И то, и то приводит к тому, что начинает наводиться прозрачность уже по инициативе заказчика. Так, как он считает нужным и правильным.

Падение отношений из квадрата D в квадрат A неминуемо влияет и на команду. Только люди отвыкли писать отчеты, тут на — новая форма. Зачем, почему?

Довольно тяжело объяснять эти вещи команде. Поэтому лучше не доводить до греха, а выступать проактивно. Давайте прямо сейчас и начнем.

Падает доверие — увеличивайте прозрачность, чтобы не свалиться ниже красной черты.

Не бывает неадекватных заказчиков. Бывают заказчики, про которых мы не можем понять, почему они ведут себя именно этим образом. Когда начинаешь копаться, очень часто оказывается, что проблема именно в прозрачности. И/Или в опыте, который уже получил заказчик, работая с непрозрачными командами.
​​8 Параметров социальной жизни команды

В книге (Чарли Пелерина: How NASA builds teams) описывались социальные проблемы крупных технологических проектов, которые стоили миллионов долларов космической промышленности США.

Читая описание социальных параметров, попробуйте задаться вопросом: “Насколько хорошо функционирует этот аспект социальной жизни нашей команды?”

1. Выражение благодарности и признания. Людям нравится чувствовать признание достижений и благодарность за работу со стороны окружающих. Через выражение искреннего признания создается атмосфера взаимного уважения.

Максимум: Признание и благодарность выражаются регулярно, искренне, своевременно, конкретно и соразмерно вкладу участников.

2. Знание и использование общих интересов. Люди предпочитают взаимодействие личным интересам, когда понимают общие цели и выгоды от совместной работы. «Интересы» — это выражение ценностей и взглядов. Можно определить общие интересы задаваясь вопросом: «Что они хотят такого, чего я тоже для них хочу?».

Максимум: Члены команды знают и используют общие интересы, особенно в разрешении споров и конфликтов.

3. Правильное включение в процессы. Людям важно ощущать сопричастность так же, как и признание. Мы чувствуем «включенность» через обмен информацией, делегирование, выражение и учет мнений. Типичный пример недостаточного включения — принятие важного для всех решения неполным составом команды. Пример избыточного включение — скука на встречах и злоупотребление опциями СС и “Ответить всем” в почте.

Максимум: Члены команды обмениваются информацией, принимают решения, участвуют в реализации, избегая недостаточного или расточительного вовлечения.

4. Соблюдение всех договоренностей. Людям нравится работать в атмосфере доверия, а доверие развивается путем соблюдения договоренностей. Кроме этого, правила принимаются и выполняются, что бы повысить эффективность работы. Если придерживаться договоренностей сложно, прежде чем от них отказаться или нарушить — обязательно обсудите причины и способы их корректировки.

Максимум: Команда принимает только те правила, которые все участники договорились соблюдать. Члены команды строго следуют договоренностям.

5. Выражение реалистичного оптимизма. Людям важно верить в позитивное будущее. Оптимизм усиливается через понимание конечных выгод и соотнесение с ними временных трудностей. Проблемы важно обсуждать открыто и своевременно, в атмосфере поддержки и здравого оптимизма.

Максимум: Все участники понимают цели и верят в их достижимость. Команда придерживается оптимистичного настроя даже когда сталкивается с трудностями.

6. Приверженность конечной цели. Фокусирование на конечной цели повышает энергию и вовлеченность команды. Люди, нацеленные на результат, переживают изменение восприятия и начинают видеть дополнительные возможности (Возможно, в русском языке есть похожая поговорка: «Where attention goes, power flows»).

Максимум: Члены команды демонстрируют 100% приверженность и следование общим целям.

7. Отпор обвинителям и жалобщикам. Состояния драмы отнимают слишком много энергии. Фокусируйтесь на разрешении проблем вместо поиска виновных или обстоятельств. Не вступайте в “клуб” жертв и агрессоров и культура команды станет более здоровой.

Максимум: В команде не принято обвинять других или жаловаться на обстоятельства. Члены команды избегают таких способов ухода от ответственности и помогают в этом другим.

8. Ясность функций, подотчетности и полномочий. Успех определяется через соответствие ожиданиям или возможность их превзойти. Прояснение ролей, функций, подотчетности, ожидаемых результатов и власти, необходимой для их достижения – помогает команде работать успешно.

Максимум: Ожидания от ролей членов команды ясны. Зоны ответственности распределены и снабжены соответствующими полномочиями. Ожидания согласованы со всеми важными сторонами.
​​Как обычно назначают TeamLead'a

Казалась бы, что сложного? TeamLead (TL) — это что-то среднее между менеджером и классным техническим специалистом. Раз у нас в компании нет менеджеров с подходящими знаниями, давайте сделаем Васю TL, он же крутой программист. Поздравляю, вы только что ступили на дорогу в ад.

На мой взгляд, есть 2 крупные ошибки, которые совершает руководитель или текущий TL.

Ошибка №1. Искать кандидата на эту должность надо, не когда вы об этом задумались, а когда сами стали TL. Зачем мне сразу искать себе замену? Предположим, у вас классная команда специалистов, но они ни разу не управляли людьми. Этому навыку надо учиться, также как вы учитесь писать код.Занимает это массу времени, на мой взгляд от 2 до 4 лет. Тимлидами не рождаются, ими становятся. То же самое, чтобы научится кататься на велосипеде, нам нужно несколько раз упасть. Бывают, конечно, исключения из правил, у человека уже могут быть задатки, но давайте не будем полагаться на случай.

Ошибка №2. Далеко не факт, что хороший технарь будет хорошим руководителем. Переводя инженера на должность руководителя, вы кидаете его в новый незнакомый мир, вытаскиваете его из зоны комфорта. С таким стрессом справится не каждый. Велики риски, что человек перегорит, может вообще уволиться. То есть так можно не только остаться без TL, но и потерять хорошего программиста.

TL начинают искать сразу по нескольким причинам. Во-первых, велик риск ошибки, вы должны успеть хорошенько присмотреться к человеку. Во-вторых, вам не повредит игрок на скамейке запасных, например, в случае форс-мажора, когда TL в отпуске, на больничном или вообще уходит из компании.

Так как мы все разные, сложно предугадать, как человек будет развиваться. Наша задача — отобрать кандидатов, у которых есть задатки к руководству и интерес к такой деятельности, подвести к новым обязанностям и научить.

TL не рождаются из воздуха, поэтому есть два пути, каждый со своими плюсами и минусами. Выбор за вами.

Найм со стороны:
Плюсы: готовая боевая единица, не надо тратить ресурсы (время и деньги) на обучение.
Минусы: кот в мешке — есть шанс ошибиться, может не разделять ценностей команды, время на получения доверия команды.

Выращивание своими силами:
Плюсы: шанс ошибки выбора сводится к минимуму, большой кредит доверия команды.
Минусы: трата ресурсов (времени и денег) на обучение.
​​TeamLead назначен. Что дальше?

Приходит час Х, пора назначать нового тимлида. Вы смотрите на кандидатов и их заслуги и принимаете осознанное решение. Иногда сложно выбрать, а иной раз вы уже точно знаете, кто будет TL. В моей практике обычно большинство отсеивалось в процессе отбора, и чаще даже не приходилось выбирать.

Конечно, хорошо, когда команда готова и согласна с новым лидером, но может сложиться ситуация, когда из двух сильных кандидатов вы выбираете одного и отказываете другому. Обязательно объясните второму, почему его не выбрали, какие навыки подтянуть. Скажите, что оценили его и готовы в будущем попробовать опять на роль TL. Конечно, не всё может пройти гладко, но универсального ответа нет.

Итак, у вас новый TL и его команда. На этом работа по его становлению не заканчивается. Вы по-прежнему занимаетесь менторством и помогаете ему. Важно продолжать ему передавать свои знания и умения, но ни в коем случае не решать за него. Максимум — разбор ситуаций с анализом, но решения должны оставаться за ним.

Процесс запущен, и всё идёт своим чередом. Наконец-то можно расслабиться и сосредоточиться на своих делах? Нет, необходимо продолжать держать руку на пульсе и следить за ситуацией. Не относитесь к этому халатно, мол само настроится. Ошибки TL куда дороже для компании, чем ошибки рядовых разработчиков. Кроме того, если процесс будет нарушен, то и с командой могут начаться проблемы. Поэтому лучше сделать сразу хорошо, чем потом всё ломать и начинать сначала.

Продолжайте обсуждать с новым TL какие-то решения, раз за разом убеждайтесь, что он правильно понимает принципы планирования и приоритизации задач, понимает задачи с точки зрения бизнеса и стремится их сделать так, чтобы они работали именно для бизнеса. Он должен задаваться вопросами о сроках и планировать риски, а также осознавать, что ему тоже надо искать себе на замену TL. Объясните про выгорание: если он будет вкалывать месяц, выкладываясь на все сто, то рано или поздно придёт отходняк. Будет печально, если вы упустите этот момент и лишитесь специалиста. Только после того, как человек освоится, можно будет потихоньку отпускать его в свободное плавание.

А что если взять готового?

По сути, это все те же показатели, только вам надо получить результат гораздо раньше — в течение испытательного срока. Только сложность состоит в том, что человек ещё должен влиться в новую команду, его мотивации и ценности должны быть в одной плоскости с компанией.

Здесь важно понимать, что до этого новый TL работал по другому, у него были другие ценности. А ваши ценности ему не знакомы. Хорошо если вы смогли это определить на стадии собеседований. На мой взгляд, вкладываться в наемного TeamLead'a приходится больше и упорней. И гарантий, так же нет.
​​Своевременность: Атака в прошлое

Слышали ли вы когда-нибудь в свой адрес упреки в неконструктивности? Может быть, сами кого-то упрекали? Как вы понимаете, что вот это конкретное обсуждение не конструктивно, а вот это конструктивно?

Казалось бы, ежу понятно, что проблемы надо решать тогда, когда их надо решать. Ведь неспроста, когда кто-то нам говорит: “Ну. я еще месяц назад видел, что у вас тут скорее всего все завалится, и действительно...” — хочется забить гвоздь в голову этому наблюдательному человеку.

Но в реальной жизни все немного сложнее.

Прибегает, например, менеджер к своему сотруднику с сакраментальным вопросом: “ПОЧЕМУ ты вчера не прогнал тесты?!!” Что в этот момент сделать сотруднику? Сесть в машину времени, метнуться в прошлое, там прогнать тесты и вернуться с уже прогнанными тестами?

С прошлым есть ровно одна проблема — его нельзя изменить. Поэтому вопросы в прошлое люди зачастую воспринимают как атаку на них лично. Более того, на вопрос “Почему ты не сделал вчера вот это” человек начинает добросовестно отвечать, почему он вчера этого не сделал. Причин у умных людей всегда много: соседний отдел поздно прислал требования, потом другой отдел долго не мог сделать сборку, тут еще директор отвлек на важную задачу и т.д.

На самом деле, то, что тесты не были прогнаны, само по себе не хорошо и не плохо. Это некий факт. Я, вот например, тоже вчера тесты не прогнал. Более того, я их уже лет пять тесты не гоняю. И пока все довольны.

Но по накалу эмоций, этот факт создает какую-то проблему В НАСТОЯЩЕМ. Например, менеджер не может отправить сборку заказчику. Или не может рапортовать об успешном завершении работ наверх и т.д. И вот эту проблему и надо решать в настоящем.

А когда она решена — тут как раз можно заглянуть В БУДУЩЕЕ: как бы нам сделать так, чтобы таких ситуаций больше не повторялось. И вот здесь будет уместен анализ прошлого: почему тогда тесты-то не прогнали? Но в этой точке человек уже не воспринимает это атаку на него личного. Когда текущая проблема разрешилась, виноватых уже не ищут. Мы вообще теперь будущее обсуждаем.

То есть, правильная последовательность обсуждения:
1. Решаем проблему в настоящем. Здесь про прошлое не вспоминаем.
2. Думаем, как предотвратить (или отреагировать) проблему в будущем. И на это этапе:
- Анализируем прошлое
Своевременность: Одну проблему решили, о второй забыли

Начнем с примера №1.

За настройку рабочего окружения отвечает удаленный сотрудник. На работу выходит нового сотрудника. Он звонит удаленщику с просьбой что-то ему настроить, и тот четыре часа объясняет, почему этого сделать нельзя. После этого новый сотрудник в расстроенных чувствах подходит к руководителю, и руководитель ему за пять минут все настраиваю.
— А дальше?
— А дальше ситуация повторяется с некой периодичностью.

Что в реальности происходит? Руководитель отлично решает возникшую проблему — настроить окружение новому сотруднику. Однако после этого забывает заглянуть в будущее и подумать, как сделать так, чтобы ситуация не повторялась.


Пример №2.

— Я хотел бы научиться отказываться от проектов.
— ?..
— Понимаете, сейчас я работаю на пятью проектами одновременно. И мне очень тяжело. Я хотел бы, когда мне принесут шестой проект, как-то так ловко от него отказаться, чтобы не взять его себе, и чтобы руководство тоже не обиделось.
— А что было, когда вам давали пятый проект?
— [после паузы] Я работал над четырьмя… Мне было очень тяжело… Я им говорил, что не потяну… А они сказали, что очень надо…
— Ну и как, вы потянули?
— Потянул…
— Тогда руководство знает, как дать вам и шестой проект…

Довольно часто руководство и заказчики приходят к нам со срочными просьбами о совершении подвига. И на слова “это невозможно” всегда находится аргумент “ребята, очень надо”. После чего, мы обычно беремся за этот проект, не спим ночами и совершаем небольшое чудо. Выдыхаем и надеемся спокойно поработать дальше. И это не получается.

Как эта ситуация выглядит со стороны руководства? Приходишь к ребятам, просишь что-то сделать. Они поначалу сопротивляются, говорят, что невозможно, но после аргумента “очень надо” — берут и делают, большие молодцы!

Или наоборот, руководство начинает подозревать, что когда вы говорите “невозможно”, то мягко говоря лукавите. Значит, и дальше надо грузить.

Ни один реальный подвиг не должен оставаться не “проданным”. Любой подвиг — это повод для обсуждения с заказчиком подвига (после совершения, когда заказчик находится в приятственном расположении духа, хорошо к вам относится и готов вас слушать): “Как там, все нормально? Так вот, я поэтому и пришел. То, что произошло — это чудо, потому что… Как бы нам так сделать, чтобы это все предусмотреть и в следующий раз вас не подвести?”

Зачастую решение одной проблемы создает следующую, которую мы упускаем из виду. И это тоже распространенное нарушение принципа своевременности.
​​Аргументы и факты

Иногда люди абсолютно искренне не видят проблему, которую вы пришли обсуждать. У каждого свой опыт.

Положим, вы убежденный сторонник гибких методологий разработки. Соответственно, у вас в команде проходят утренние планерки (они же скрам-митинги или standup-митинги). И вот ваш новый коллега на них постоянно опаздывает. Почему?

Он может искренне считать, что это полная ерунда. Потому что до этого он работал десять лет в других компаниях и других проектах. И они вполне успешно делали проекты без всяких ритуальных планерок.

«Это ухудшает командный дух» — отличный аргумент, но в чем это выражается? Что такое командный дух? Это когда заходишь в комнату, а там такой «сильный командный дух» витает в воздухе?!

«В чем это выражается?» — мощный вопрос, позволяющий понять, есть в аргументе факты или нет. Факты хороши тем, что с ними не поспоришь.

Такие аргументы, как «это лучшие политики Agile», «это правила нашей компании», «так завещал Кен Швабер», кстати говоря, хоть и являются фактами, но немногим лучше, поскольку не показывают, что конкретно не так из-за поведения человека.

А такие аргументы, как:
— «мы не можем учесть твое мнение, потом уже не раз приходилось переделывать»;
— «все интересные задачи разбирают до твоего прихода»;
— «тебе остаются только рутинные»;
— «на рутинных задачах я не могу оценить твой рост»,

это более конкретные факты, потому что они показывают, что в этой ситуации не так и почему вы вообще решили обсудить эту проблему.
​​Намерение решить проблему, а не человека

В рамках конструктивного обсуждения мы не ищем виноватых. Наша задача — решить ситуацию.

Если по ходу обсуждения возникает ощущение, что человек пытается доказать, что он не виноват, то очень неплохо работает прием диссоциации: «Погоди, я не на тебя наезжаю, но сама ситуация…»

Пример из жизни. У меня трое детей. Подростку — 15 лет. Когда приходишь к нему с конструктивной критикой, первой фразой очень часто бывает: «Я не виноват».

Со временем вошло в привычку выруливать: «Так я не про “виноват, не виноват”. Просто как теперь…» — и дальше возможны варианты «пойдем играть в футбол, если ботинки мокрые», «посмотрим фильм, если нам сейчас надо будет убираться» и т. д.

Данный формат вовлекает в решение проблемы "виновника" ситуации. Заставляет его думать и приучает анализировать ситуацию.
​​Agile-лидер

Обеспечивает общее, понятное всем видение процесса и цели. Иметь четкие критерии успеха. И понимание, чего делать не надо.

С одной стороны он: Вовлекает людей в работу, вызывает у них доверие и симпатию. С другой стороны Agile–лидер: Разрушает бюрократию в компании, придумывает более эффективные способы работы, переосмысливает процессы.

Организация разрастается, у команд появляется несогласованность, им все сложнее контактировать друг с другом, размывается цель и результат. Задача Agile–лидера создать у всех участников процесса единую картину: где мы, куда и зачем идем. Кроме того, он создает условия для самоорганизации команд и процессов в них. Создает благоприятный контекст, проектирует среду, чтобы это происходило.

Список задач Agile–лидера:
- Обеспечивает общее, понятное всем видение процесса. Все команды, клиенты и другие ключевые фигуры видят цель и идут к ней. У них есть критерии успеха, которые основаны на влиянии на бизнес. И понимание, чего делать НЕ НАДО.
- Добивается того, что работа делится на части, результаты анализируют и корректируют. Клиентам поэтапно демонстрируют продукт.
- Обеспечивает создание адаптивных планов и их распространение между командами и другими участниками процесса. Адаптивность в том, что как только появляется новый опыт и знания, планы можно легко изменить и перестроить.
- Согласовывает сроки и объемы работ со всеми участниками.
- Обеспечивает обратную связь между командами и клиентами. Это и совместное планирование, и демонстрации продукта, и тестирование гипотез.
- Создает условия для обучения сотрудников и передачи ключевых знаний от одной команды к другой.
- Мотивирует команды брать ответственность, и какие–то вопросы решать самостоятельно.
- Убирает препятствия и решает проблемы, которые демотивируют людей. Например, разруливает проблему зависания серверов с системными администраторами, закупает нужные книги для библиотеки или формирует ее с нуля, улучшает доску.
- Создает условия, чтобы все решения ответственные лица принимали вовремя, без задержек.
- Держит руку на пульсе HR–отдела. Следит за тем, чтобы нужный персонал вовремя нанимали. Планирует загрузку сотрудников.
- Делает все, чтобы команды не простаивали в ожидании друг друга.
- Людей и общение между ними ставит выше инструментов и документации.
- Создает условия, при которых ошибки и провалы случаются на ранних этапах, а не в самом конце (а лучше, если не случаются вовсе).

Список обязанностей кажется огромным, правда? Но на самом деле компании стоит выделить ТОП-5 важных для нее пунктов. Например, то, что проседает прямо сейчас. И сделать их приоритетными для Agile–лидера.
​​CRC - карты

CRC — карты предназначены для упрощения первого этапа проектирования и анализ задач объектно–ориентированного программного обеспечения. Их составление представляет процесс мозгового штурма в целях определения классов и их взаимодействия для концентрирования разработчиков на первостепенных задачах и во избежание излишнего внимания к прочим задачам.

Применение метода CRC – карт представляет собой игровой процесс, роли классов в которой распределяются между разработчиками. Команда собирается для проработки различных сценариев с помощью карт.

CRC – карта в своей структуре имеет следующие поля: верхнее – название класса, левое нижнее – ответственность, правое нижнее – связи класса.

Верхнее поле – название класса (Class). Эти данные берутся из технического задания или иного документа с задачами. На каждый элемент заводится класс. Именно он и выносится в шапку CRC — карты.

Нижнее левое поле – ответственность (Responsibility). Это информация о том, за что отвечает класс. Здесь парой слов описывается функция объекта, или операция, которую он выполняет, объем информации объекта, а также здесь могут быть указаны решения, принимаемые объектом. Зачастую, после анализа ответственностей, они перераспределяются между классами. По итогу обработки они становятся методами класса.

Нижнее правое поле – связи (Collaboration). Это поле отражает функционал класса при его взаимодействии с другими классами. В итоге карточки должны образовать целостную модель взаимодействия.

Команда собирается для проработки различных сценариев с помощью карт. Происходит это посредствам передачи карт друг другу в виде сообщений. Сценарии могут быть подготовлены заранее, однако в процессе игры зачастую выявляются совершенно неожиданные варианты. Очень сложно описать эту технологию методологически, но в процессе она незамысловата и максимально легка.

Одним из самых важных моментов является распределение ответственности (нижнее левое поле — Responsibility). Нужно разумно описать обязанности объекта, что поможет сформировать иерархическую структуру модели. Важность проработки ответственностей заключается в возможности абстрагироваться от мысли о классе, как о хранителе данных. Они создают понимание о функционале класса на каждом уровне иерархии. Помимо указанного ранее, ответственность также может распределяться по операциям, атрибутам п пр.

Обычно опытные разработчики советуют не создавать длинных списков очень низких ответственностей, так как это, в конечном счете, сбивает с основной мысли и может привести к необоснованному разделению классов. Рекомендуют лаконично, в паре слов излагать суть ответственности и переносить их в другие уровни иерархии при необходимости.

При проработке связей необходимо также быть максимально внимательными, так как должны быть учтены все возможные случаи взаимодействия объектов друг с другом. Без этого модель может быть незавершенной.

На основании совокупности карт, сложенных в модель, в конечном итоге строятся CRC–диаграммы. Обычно, по итогу проработки иерархии с помощью CRC – карт выработанная модель передается на UML моделирование, где происходит детализация анализа и задач. Есть случаи, когда стадии составления CRC – диаграммы уже достаточно.
​​Как выбрать формат для мозгового штурма

Правильно организованный и подобранный формат для мозгового штурма (или грумминга) позволяет не только экономить время, но и обеспечить большую вовлеченность участников.

Очередность

Последовательно

В данном случае ведущий выбирает любую последовательность, которую будут соблюдать участники. Это может быть «по часовой стрелки», «по алфавиту фамилии» и т. д. Здесь важно, чтобы порядок не имел отношение к рабочей деятельности («по должности», «по рангу», «по стажу» и прочее).

Преимущества данного подхода в том, что все говорят приблизительно одинаковое время, что в свою очередь повышает инклюзивность. Так же это дает время подумать на своими следующими ответами.

Но, к сожалению, данный способ, не работает с большими группами (более 10 человек).

Хаотический

При таком подходе любой может высказаться в любом порядке. Данный способ будет хорошо работать, если тема не спорная и вам не требуется большое количество идей или ответов.

«Когда в следующий раз проведем корпоратив» - идеальный вариант для данной очередности.

Недостатком является то, что в основном будут говорить смелые, экстравертные коллеги. Многие коллеги останутся без возможности высказаться.

Документирование встречи

Никто не записывает – самый простой вариант. Простая, открытая дискуссия в которой все более вовлечены, чем при протоколировании встречи.

Идеально подходит для работы в малых группах (до 5 человек) и, если планируется результат получить и утвердить на встрече.

Использование стикеров, хороший вариант, когда надо на генерировать много идей. И при этом не выделять роль центрального «летописца». Но надо будет заложить время на удаление дубликатов стикеров.

Почти идеально подходит для интровертов и вечно молчащих коллегах.

Важно в данном подходе ограничивать время написание стикеров 2–4 минутами.

Записывает ведущий – легкий способ для участников, который позволяет им сосредоточиться только на теме мозгового штурма. Так же данный метод, лучше использовать, если требуется использовать различную терминологию, с которой не все могут быть знакомы.

Назначить ответственного – позволяет освободить внимание ведущего и участников на штурме идей. В данном случае, большую роль играет правильный выбор ответственного. Человек, который не может быстро записывать, слушать сразу много человек одновременно и не ориентируется в предметной области, скорей всего не справиться с активной и горячей дискуссией.
​​Как заставить стендапы работать

Чтобы исправить наши стендапы, мы должны изменить их назначение. Мы должны проводить эти встречи так, чтобы фокусироваться на наших целях, и корректировать эти цели по мере поступления новой информации.

Стендапы могут быть полезными: это отличный способ без лишних затрат задать ритм. Когда каждый день в календаре у каждого члена команды есть фиксированное время, люди организуются вокруг него, сокращая накладные расходы на планирование встреч с занятыми коллегами.

Кроме того, когда система ежедневно выдает синхронную превентивную обратную связь, для выявления проблемы потребуется максимум один день.

1. Прекратите болтать. Пройдитесь по Канбан-доске

Работа с доской Канбан решает многие проблемы. Это мотивирует людей быть краткими, потому что фокус на цели спринта, а не на чьей-то продуктивности. Вместо того, чтобы объяснять, что они делали, и все мельчайшие технические детали, инженеры сосредотачиваются на том, нужна ли им помощь и что они должны сделать, чтобы переместить конкретный элемент в правую часть доски: в колонку «Done».

Кроме того, это стимулирует команду визуализировать и отслеживать работу, которая в противном случае осталась бы невидимой. Если появится критическая ошибка, люди добавят ее на доску, чтобы они могли попросить других о помощи и предупредить всех о том, что что-то происходит.

Так, же этот подход заставляет людей удилять больше внимание на этапе планирования спринта. Лучше прогнозировать сроки.

2. Сосредоточьтесь на блокирующих работу факторах

Если проблема только проявилась, возможно разработчику не стоит сообщать о ней всем, если только это не блокер или есть вероятность скорого появления блокера.

После сообщения о блокерах команда должна обсудить, что они должны сделать, чтобы разблокировать задачу. Чем дольше задача остается заблокированной, тем больше становится среднее время цикла и менее предсказуемыми становятся команды. Помните: завершение начатого делает команду более продуктивной и предсказуемой.

3. Переместите детальные обсуждения в асинхронный режим

Всякий раз, когда инженеры попадают в ловушку обсуждения глубоких технических вопросов, выносите эти обсуждения в асинхронный режим и включайте в последующее обсуждение только тех, кто заинтересован.

Если люди вынуждены слушать обсуждения неинтересных тем, которые не способствуют продвижению к цели команды, люди – обоснованно – перестанут приходить на стендапы (или начнут жаловаться на них, как мы сейчас).

Воспринимайте стендап встречу как время для выявления проблем, а не как время для их решения.

4. Стимулируйте самоуправление и создавайте атмосферу психологической безопасности

Когда людей наказывают за выявление проблем, они перестают это делать. Следовательно, проблемы проявятся только тогда, когда они станут слишком критичными или почти неразрешимыми. Вместо этого вы должны стимулировать команду озвучивать проблемы, как только они появляются.

При раннем выявлении проблемы обычно легко решаются. Например, изменение проблемной спецификации обычно обходится намного дешевле, чем попытка исправить критическую ошибку в производственной среде.

В атмосфере психологической безопасности члены команды знают, что любые вопросы уместны. Вместо того, чтобы предполагать что они знают ответ и только усугубить проблему в будущем, они просто лишний раз спросят, понимая что за это не будет наказания.
Как сплотить команду в трудные времена

В этих обстоятельствах надо действовать открыто, спокойно и последовательно. И постоянно держать руку на пульсе. Иначе легко упустить команду, подорвав доверие, которые вы выстраивали годами.

Расскажите о планах. Не нужно делать вид, что ничего не происходит. Если вы избегаете темы и при этом излучаете спокойствие, сотрудники могут решить, что вы владеете информаций «не для всех», о которой они узнают в последний момент, если вообще узнают. Это посеет недоверие и раздор.

Соберите команду и расскажите, как внешние изменения повлияют на работу компании и подразделения. Какие есть риски и новые возможности, какие направления прорабатывает руководство, какие есть сценарии дальнейшего развития событий.

Управляйте твёрдо и оказывайте поддержку. Когда ломается привычная система, даже умные и опытные люди впадают в дезориентацию. Чтобы команда не утонула в апатии и хаосе, временно переходите на штабной тип управления, но обязательно с элементами тренерства.

Тем, кто с трудом справляется с беспокойством и упадком сил, сейчас нужна чёткая постановка задач, разбивка больших работ на малые и точность в сроках. Самых деятельных сотрудников на фоне стресса может заносить не туда. Им нужны более частые, чем обычно, синхронизации с руководителем и командой и тщательный контроль.

Полностью переходить на командирский стиль руководства избыточно и непродуктивно. Но в кризисные моменты люди чувствуют себя безопаснее, зная, что можно опереться на крепкое плечо. Совмещайте твёрдость с индивидуальным подходом к каждому.

Если вы свели к минимуму количество встреч, на время можно вернуть, как было. Например, возродить утренние планёрки. Они добавляют в жизнь рутину, а рутина помогает пережить неопределённость.

Предостерегите от необдуманных действий. Сейчас легко потерять самообладание и принять спонтанное решение, о котором, возможно, придётся жалеть в будущем. Если вы видите, что сотрудник в смятении спешит сделать что-то радикальное: уволиться, распродать имущество, взять билет в один конец, помогите ему остудить голову.

Задайте несколько вопросов, которые помогут всё обдумать и составить план хотя бы на ближайшее время:
- Если сотрудник собрался уезжать, планирует ли он остаться в компании?
- Знает ли он, как будет получать зарплату в другой стране, с учётом возможных ограничений?
- Если задумал уволиться, нашёл ли он новую работу или едет «в никуда»?
- Как планирует её искать?
- Учитывает ли резко изменившуюся ситуацию на рынке труда?
- Есть ли у него финансовая подушка или альтернативный доход?

Остановить того, кто уже принял решение, вряд ли получится, да и незачем. Но за то, что помогли внести ясность, вам точно будут благодарны.

Помогите справиться с беспомощностью. Если у вас достаточно опыта работы с мотивацией, попробуйте повести аналог мотивационной сессии для самых восприимчивых сотрудников. Пока человек подавлен или мечется в панике, пользы от него немного. Помогите ему справиться с беспомощностью и настроиться на конструктивное состояние, задавая правильные вопросы.

Шаг 1. Выясните проблему. Задайте серию открытых и уточняющих вопросов, чтобы сотрудник увидел, что на самом деле вывело его из равновесия. Проговорите найденную проблему и выясните отношение к ней самого сотрудника.

Шаг 2. Поддержите. Не бросайтесь в крайности, вроде: «Я так тебя понимаю! Сам/а еле держусь!». Но признайте, что ситуация тяжёлая и нормально, столкнувшись с ней, испытывать страх, бессилие, гнев и т. д.

Шаг 3. Дайте понять, что каким бы ужасным ни казалось положение, не стоит опускать руки. Надо постепенно прийти в себя, собраться и начать искать варианты выхода.

Шаг 4. Поддержите сотрудника в поиске решения, покажите спектр возможностей, задавайте открытые вопросы, чтобы понять, в каком направлении он думает. Сотрудник должен сам выбрать подходящий вариант или предложить свой. Не стоит предлагать готовые решения, иначе вы возьмёте его ответственность на себя.
Шаг 5. Мотивируйте на достижение. Помогите составить план действий. Распишите конкретные шаги и сроки, чтобы план стал реалистичным. Если нужно, договоритесь о новых встречах, чтобы инициатива не спустилась на тормозах.

Если опыта работы с мотивацией у вас пока мало, не рискуйте. Лучше посоветуйте сотруднику обратиться к психологу. Или поддержите организацию психологической помощи в компании.

Переключите внимание и создайте точки объединения. Чтобы снизить градус тревожности, помогите сотрудникам расслабиться и получить полезную информацию. Уделите больше внимания спортивным и велнесс-программам.
Организуйте занятия по изучению языков, личному финансовому планированию, информационной гигиене и критическому мышлению. Разовые или систематические групповые встречи на актуальные темы помогают не оставаться один на один с плохими мыслями и сплачивают команду.
​​Фреймворк Fit For Purpose

Fit For Purpose — это фреймворк для определения и работы с теми показателями бизнеса, которые на самом деле имеют значение для удовлетворенности клиентов. Этот фреймворк позволяет определять, на основании чего пользователь принимают решение об использовании продукта и что для них на самом деле важно.

Где нам стоит вкладывать ресурсы нужны и улучшать процессы, а где этого не стоит делать — важный и нетривиальный вопрос. Важно то, что на него может ответить только клиент, пользователь продукта. Если вы будете отталкиваться от чего–то другого, то у вас есть риск вложить много ресурсов в улучшение метрик, которые не влияют на такие вещи, как удовлетворенность пользователя и их количество.

Теория Fit For Purpose
Fit For Purpose Framework базируется на нескольких ключевых идеях.

- У ваших пользователей есть цели.
- У них есть критерии, на которые они ориентируются при принятии решения.
- Продукт может в разной степени соответствовать целям пользователя.
- Продукт может в разной степени удовлетворять важным критериям для принятия решений.

Количество критериев для принятия решения на самом деле очень невелико и не совсем не очевидно какой критерий покупателем использован.

Эксперименты в Fit For Purpose
Фреймворк Fit For Purpose предлагает эволюционный подход — то есть мы можем делать какие–то «мутации» нашего продукта и услуги, и не только содержание его, но и то как мы его поставляем.

Сбор историй от персонала
Один подход состоит в сборе каких–то историй и рассказов от персонала, который непосредственно взаимодействует с покупателями. Это должны быть люди, которые встречаются лицом к лицу с покупателями каждый день и они знают, зачем собственно покупатели приходят к нам что они просят, что они хотят с этим продуктом делать.

Вопросы непосредственно к пользователям
С помощью грамотных вопросов к пользователям можно эффективно оценивать то, насколько продукты и услуги удовлетворили ожиданиям пользователя. Если что–то их не удовлетворило — это то узкое место, где возник зазор, который мы поможем попытаться устранить.

Какие должны быть вопросы в Fit For Purpose
Вопросы должны быть острыми. Вопросы должны быть не о том «насколько вы порекомендуете нас» — это пример не острого вопроса.

Острый вопрос будет состоять в том что мы будем их спрашиваете пользователя конкретно об их опыте с продуктом или услугой которыми они уже воспользовались или вот–вот получат и мы будем говорить конкретно о цели, ради которой они этот продукт или услугу купили.

Количественные критерии соответствия в фреймворке Fit For Purpose
Качественные особенности фреймворка особенно очевидны — вам нужно общение с людьми, выявление того, что важно, и принятие решения на основе этих данных. Это часто идет за рамками любых цифр и количественных метрик.

В то же время часто есть и привязка к количественным данным.

В частности, мы можем, например, оценить соответствие продукта или услуги текущего состояния на конкретном сегменте рынка или по всему рынку. Мы можем узнать, например, что 60% покупателей в таком–то сегменте удовлетворены данным продуктом, а в другом сегменте — 20%. Это фокусирует, позволяет увидеть, куда нужно направить наше внимание и силы.
​​Метод Лесенки

Для того, чтобы разобраться, как искать глубинную, или истинную, мотивацию в обучении, советую использовать метод «лесенки».

Если хотите пройти обучение для каких-то рабочих процессов, используйте вопрос: «Что я должен научиться делать?» Ответ формулируйте через действие.

Я хочу изучать JavaScript → Что я должен научиться делать? → Я должен научится применять JavaScript в web-страницах.

Вариант «Я должен научиться писать на JavaScript» общий и трудноизмеримый. В нем нет точной цели с логическим завершением. А в формулировке «Я должен научится применять JavaScript в web-страницах»‎ уже становится понятно, для чего именно нужен навык.

Если сложно указать цель с четкими контурами, обозначьте так, чтобы появилась понятная рамка. Например, не «научиться писать на JavaScript», а «изучить основы JavaScript» или «освоить навыки, необходимые для джуна». Так в процессе изучения сможете лучше разобраться, что является основами, и цель приобретет логическое завершение.

Когда определились с действием, задайте себе вопрос → зачем? Он поможет разобраться и обосновать самому себе, для чего нужно научиться этому действию.

Я должен научится применять JavaScript в web-страницах → Зачем мне это нужно? → Чтобы отправить резюме на позицию джуна в Ozon.

Как понять, что вы нашли мотивацию?

1. Каждый раз, когда отвечаете на вопрос «А зачем?»:

- подвергайте ответ сомнению: убедили ли вы себя?
- прислушайтесь к отклику: драйвит ли вас ответ?

2. Задавать дальше вопрос «А зачем?» больше нет смысла, дошли до абсурда.

Почему важно быть честным?

Есть прямая зависимость между честностью с самим собой и эффективностью подхода. Увы, люди не всегда готовы признать свои истинные мотивы.

— Деньги? Нет, я же не корыстный человек!
— Повышение авторитета и признание коллег? Быть тщеславным недостойно, я не такой!

Эти и другие отрицания корнями уходят во внутренние блоки. Без честности есть риск остаться на поверхности и не докопаться до сути мотивации. Если преодолеть блоки трудно, стоит обратиться к психологу или коучу.
​​Вовлеченность сотрудников

Вовлеченность сотрудников – это сила психической и эмоциональной связи, которую работники чувствуют по отношению к компании. Вовлеченность сотрудников – это НЕ то же самое, что счастье, удовлетворение или благополучие:

Вовлеченность сотрудников – это не счастье. Разговоры коллегами за обедом, радость от праздничной вечеринки ничего не говорит о том, как усердно персонал работает для достижения цели компании. Счастье – это краткосрочное, быстро меняющееся измерение, на которое не стоит опираться.

Вовлеченность сотрудников не является удовлетворением. Удовлетворенность сотрудников измеряет минимальный уровень, в то время как вовлеченность пытается заставить всех достичь большего. Хотя удовлетворенности, как правило, достаточно, чтобы сохранить сотрудников, часто этого недостаточно для обеспечения производительности.

Вовлеченность сотрудников не является благосостоянием. Благосостояние рассматривает каждую область жизни сотрудника (как внутри, так и вне офиса), чтобы определить, насколько хорошо человек справляется со стрессом, продуктивно работает, вносит вклад в сообщество и реализует свой потенциал.

Почему важно оценивать вовлеченность
Первым шагом к улучшению чего-либо является его измерение. Чтобы сотрудник был вовлечен, он должен верить, что компания действительно заботится о нем. Когда руководитель показывает, что ему небезразличен уровень комфорта работы команды, работники отвечают повышением эффективности и большей лояльностью.

Измеряя и улучшая вовлеченность, вы демонстрируете сотрудникам, что искренне заботитесь об их благополучии и прилагаете сознательные усилия для того, чтобы люди были довольны на работе. Только этого иногда бывает достаточно, чтобы сотрудники более ответственно начали подходить к своим задачам.

Важно понимать, если вы оцениваете уровень вовлеченности, то должны быть готовы действовать. Многие организации проводят опросы, но не действуют. Нет ничего хуже, чем спрашивать у ваших сотрудников их мнение и ничего не делать с их отзывами.
​​Gallup Q12

Исследователи Gallup потратили десятилетия на написание и тестирование сотен вопросов, потому что их формулировка и порядок имеют огромное значение в точном определении уровня вовлеченности. Результат их исследований – Gallup Q12. Это 12 вопросов, которые измеряют наиболее важные элементы вовлеченности сотрудников.

Почему Q12 один из лучших способов оценить вовлеченность:
Правильные вопросы
Не задавайте много вопросов, спросите правильные. 12 вопросов Гэллапа точно определяют, что для сотрудников важнее всего.

Быстрый результат
Опросник экономит время. Gallup Q12 дает вам все необходимое, чтобы начать управлять вовлеченностью персонала уже сразу после оценки ответов.

Ориентированность на цель
Опросник помогает не упускать из виду свои цели. Результаты Gallup напрямую связаны с такими показателями, как производительность, прибыльность, удержание и текучесть кадров. Работая с результатами, можно эффективно изменить ситуацию и идти к целям компании.

Список вопросов Gallup Q12
- Знаете ли вы, чего ожидает от вас работодатель?
- У вас есть материалы и инструменты, необходимые для качественной работы?
- У вас есть возможность каждый день делать то, что вы умеете лучше всего?
- За последние семь дней вы получали признание или похвалу за хорошую работу?
- Считаете ли вы, что ваш руководитель или кто-то на работе заботится о вас как о личности?
- Кто-нибудь на работе способствует вашему развитию?
- Учитывается ли ваша точка зрения?
- Миссия и цель вашей компании заставляет вас чувствовать, что ваша работа важна?
- Считают ли ваши коллеги своей обязанностью качественно выполнять свою работу?
- У вас есть лучший друг на работе?
- За последние полгода кто-нибудь на работе говорил с вами о ваших успехах?
- В прошлом году у вас были возможности учиться и расти на работе?

Мало просто провести исследование. Самое важное — проанализировать ответы и понять, какова вовлеченность сотрудников в вашей компании и как вы можете ее улучшить.

Опросник вовлеченности персонала Q12 состоит из 12 вопросов, на которые необходимо дать ответ “да” или “нет”.

3 этапа анализа ответов
Шаг 1: посчитать количество ответов “да” и количество ответов “нет” для каждой анкеты.
Шаг 2: сложить количество ответов “да” во всех анкетах, то же самое сделать и с ответами “нет”.
Шаг 3: перевести ответы в проценты – количество, соответствующее “да” и есть процент вовлеченности для компании.

В опросе приняли участие 297 человек. Для начала выясняем сколько на всех вопросов: 29712=3564. Это число наши 100%. После подсчета выяснилось, что ответов “да” – 2743. На основе этого рассчитываем процент: (2743100%)/3564=77%

О высоком уровне вовлеченности мы можем говорить, когда процент превышает 70%. Но в целом 50+ процентов – это удовлетворительный результат, но есть над чем работать. Серьезно беспокоиться стоит, если уровень вовлеченности менее 50%.