IT-беседка

Вы никогда не найдете исполнителя для своей задачи, если будете делать так

Недавно на одной из конференций в зале взяла микрофон женщина, которая выплеснула просто крик души, что они на своем заводе по производству Х уже 4 года не могут найти исполнителя для создания цифрового двойника системы отвода воды для заводах по производству Х. Их просто нет! Конечно же тут же нашлось минимум 3 человека, которые делают цифровые двойники и могут ей помочь. Так в чем же проблема?

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

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

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

Если у вас есть сложность с поиском исполнителей или формированием команды разработки, вы всегда можете обратиться за помощью к нашей команде. Просто опишите свою проблему через нашего бота, почту [email protected] или форму на сайте, мы ответим вам в ближайшее время и предложим варианты решения.

Максим Шаламов
#руководителю #бизнесу #заказчику #разработка #поискисполнителей

Тренд или реалии современности: цифровая трансформация

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

Для начала давайте разберемся, что вообще в себя включает цифровая трансформация? По сути это перевод любых бизнес-процессов и технологий производства на цифровой, технологичный формат. Примеров конкретной цифровой трансформации и ее разновидностей такое количество, сколько разновидностей бизнесов и задач. Например, компания General Electrics использует 3D-печать для изготовления деталей для своего нового авиационного двигателя Leap Engine. Siemens внедряет умную технику для добычи руды. Netflix - по сути сам по себе компания-пример цифровой трансформации, они из обычного бизнеса полностью перешли в цифровой и очень успешно. Когда вы заходите в приложение Сбера или даже звоните по телефону вам отвечает ИИ-ассистент вместо оператора. ИТ-компании начинают использовать Copilot для написания кода своих продуктов, тот же Яндекс даже написали свой. Все это примеры цифровой трансформации. Как видите у нее очень много лиц, все зависит от задачи бизнеса. Но в целом, все, что делает ваш бизнеса более технологичным будет частью цифровой трансформации.

И на самом деле это не просто тренд последних лет, это тренд начала 21 века. Технологий появляется все больше, возможности их использовать растут и, чтобы угнаться за конкурентами, компаниям приходится просто-напросто шагать в ногу со временем. Сейчас цифровая трансформация считается трендом, потому что набирает обороты цифровизация бизнеса, есть еще многое, что работает по-старому. Да и повсеместное внедрение и развитие ИИ-технологий дало этому тренду новый толчок. Ну и не будем забывать про пандемию, которая заставила многих работать удаленно, что очень сложно сделать без цифровизации. Но по большому счету это наша реальность уже многие годы. Реальность, от которой сложно отмахнуться. Мы же не можем все еще ездить на лошади, когда наши конкуренты летают на самолетах?

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

Как понять, что именно вам в компании нужно цифровизировать уже сейчас, а с чем вы уже опаздываете? Мы будем еще углубляться в тему цифровой трансформации и эту тему тоже рассмотрим. А если вам необходима помощь уже сейчас, то пишите свой вопрос в нашего бота, на почту [email protected] или форму на сайте, мы ответим вам в ближайшее время и вместе сможем найти ближайшие шаги.

Александра Шаламова
#цифроваятрансформация #бизнеспроцессы #agile #бизнес

Шпаргалка по росту в руководителя команды

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

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

Первое, что нужно понять, что вообще из себя представляет должность руководителя:

- Карточки с описанием обязанностей руководителя команды (тимлида)
- Карточки с описанием обязанностей технического руководителя команды (техлида)
- Подробный пример, чем занят руководитель в свой рабочий день
- Чем отличается руководитель от разработчика

Дальше определяем, а нужно ли оно именно вам:
- 4 признака, что вам не дано быть руководителем
- Какие требования СТО предъявляет руководителям команд на собеседовании в том числе личные качества
- Правда ли нужно быть стрессоустойчивым, чтобы быть руководителем
- Зачем вообще становится руководителем, если разработчику итак хорошо платят?

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

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

Сохраняйте этот пост, чтобы не потерять все ссылки, пересылайте коллегам и подчинённым, чтобы помочь им найти свой путь к управлению командой. Иногда даже пара советов от опытного управленца могут сэкономить годы собственного опыта и ошибок. А если вы все уже прочитали, но у вас есть какие-то трудности, то приходите к нам карьерную консультацию. Нужно просто подать запрос через нашего бота, почту [email protected] или форму на сайте.

#руководителю #бизнес #управлениекомандой #разработка #ит #менеджмент

Почему обязательно нужно смотреть задачи вместе с командой?

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

Многие ИТ-лидеры скажут, что для для бизнеса (ПО и БЗ) то да, но я та говорю с ребятами на одном языке, у меня проблем не будет. Заманчивая точка зрения, но в корне неверная. Возьму себя и одну из своих задач 2024 года по внедрению автоматического регрессионного тестирования. Я поставил задачу, мы нарисовали дорожную карту, со всеми договорились и пошли делать. Отклонений по дорожной карте особо не было и я посмотрел демо того, что сделано уже ближе к концу. И все было бы хорошо, только я ожидал, что мы делаем регресс всего продукта, а мы сделали регресс отдельных частей (по сути поделив по командам). И это решает часть проблем, но не все, которые ожидалось.

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

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

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

Максим Шаламов
#руководителю #бизнесу #управлениекомандой #разработка #agile #гибкиеметодологии

Учет или планирование личных расходов, что лучше?

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

Мы с женой уже 3 года живем по лимитам на различные категории расходов. Отчасти это помогло нам досрочно закрыть ипотеку в конце прошлого года. Как лимиты работают у нас? Очень просто: выделяем свои категории расходов (работа и дорога, продукты, кафе и рестораны, транспорт, хобби, учеба, кредиты и т.д.) и выделяем себе лимиты на каждую категорию. В чем суть лимитов? Муть в осознанности. Это не значит, что вы никогда не выходите за лимиты, а в том, что, если вы израсходовали лимит по категории раньше времени (например вы ставили 20 000р на 20 дней, но он закончился за 17 дней), то вы идете и смотрите траты по категории и принимаете осознанное решение, что либо лимит неправильный (например, цены выросли или вы хотите в эту категорию инвестировать сильнее) или вы просто увлеклись в этом периоде и надо притормозить. Тогда запись ваших расходов поможет вам принять решение и либо разово отступить от плана, либо отказаться от трат, либо изменить лимиты.

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

А вы ведете расходы? Помогает ли вам использование лимитом? Делитесь своими подходами в комментариях.

Максим Шаламов

Заказал одно - получил другое: почему команда делает не то, что просишь?

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

Начнем с того, что обычно, так или иначе, есть три звена в работе над задачей:

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

Основные виды проблем, из-за которых заказчик получает не то, что заказывал
1. Частая история, когда бизнес-заказчик вообще слабо понимает, что он хочет, и слабо мотивирован в участии в постановке задачи. Он уверен, что все итак понятно и что там делать-то. В итоге, половину или большую часть постановки приходится делать ПО и / или команде. Даже если таким людям отдать на проверку постановку, то обычно комментариев будет немного или наоборот ситуация просто застопорится, потому что всегда будет все неправильно. В итоге, максимально абстрактно поставленная задача, получает воплощение, которое шокирует заказчика и вызывает его негодование. Если вы сами хотите научиться хорошо прорабатывать задачи или научить этому своего бизнес-заказчика, обязательно используйте наше руководство по описанию задач. В нем есть все необходимое.

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

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

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

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

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

А если вам нужно помощь с выстраивание процессов для своей разработки, вы всегда можете обратиться за к нашей команде. Просто опишите свою проблему через нашего бота, почту [email protected] или форму на сайте, мы ответим вам в ближайшее время и предложим варианты решения.

Максим Шаламов
#руководителю #бизнесу #управлениекомандой #разработка

Самоорганизующаяся команда за 6 шагов

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

https://vc.ru/dev/1770594-kak-sozdat-samoorganizuyushuyusya-komandu-razrabotki

#разработка #управлениекомандой #agile #бизнес #руководителю

Как бизнесу наладить общение с командой разработки. Часть 2

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

Формализация требований
Избегайте ненужных конфликтов за счет формализации требований. Все требования, договоренности и сроки должны быть зафиксированы. Устные договоренности не имеют смысла, если их не фиксировать. Все могут вынести разные вещи из встречи, кто-то забыл, кто-то не услышал. В итоге мы получаем кучу конфликтов на приемке или кучу обманутых ожиданий, которых вообще не должно было быть. Выберите инструмент и фиксируйте все. Проработайте задачу в том виде, как вы бы хотели ее видеть, как пользователь системы, тогда вы сможете ожидать, что получите именно то, что заказали. Иначе, вы получите, что-то, что может быть далеко от ваших ожиданий. Но если они не зафиксированы, то никакой конструктивной критики и работы над ошибками не получится. Будут только конфликты и потеря мотивации. Как хорошо фиксировать требования в задаче на разработку вы можете посмотреть в нашем руководстве по описанию задач.

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

Отслеживание процесса
Используйте системы трекинга задач и регулярные встречи для отслеживания прогресса по задачам. Не дергайте команду каждую минуту. Это очень выбивает из контекста, а так же выглядит, как недоверие, и ведет к конфликтам. Не пытайтесь оценивать задачи сами, иначе вы получите либо не работающий вариант в свои сроки, либо перенос сроков и огромное негодование своей команды. Учитесь работать по оцененным срокам, доверяйте своей команде, а если есть проблемы, то улучшайте процессы для повышения прозрачности, ну или нужно менять членов команды, которые не тянут (но это должны делать технические лидеры вашей компании, которые разбираются в специфике и работе IT, делайте это через них).

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

Заключение
Я общался с многими ПО и понимаю их проблемы: надо и развитие продукта проработать, и бюджеты утвердить, и встретиться с клиентами и пользователями и многое другое. Где тут взять время на команду? Тут нужно понимать, что если вам все же нужна команда, то все, что я написал нужно делать. Не успеваете сами? Наймите человека, который будет работать с командой, расписывать задачи, ходить на встречи, будет все время на связи. На определенном этапе развития проекта брать помощь не просто можно, но и нужно.

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

Максим Шаламов
_____________________

Если у вас есть сложность с организацией работы своей разработки, вы всегда можете обратиться за помощью к нашей команде. Просто опишите свою проблему через нашего бота, почту [email protected] или форму на сайте, мы ответим вам в ближайшее время и предложим варианты решения.

#советы #бизнесу #agile #управлениекомандой #руководителю

Мой топ-5 прочитанных книг 2024 года

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

Начну я с не профессиональной литературы. Казалось бы и зачем она нам? Что я могу полезного в этом почерпнуть? У хороших авторов (особенно в классике) вы можете посмотреть на различные типажи людей в разных ситуациях. Если автор действительно хороший, то вы будете узнавать типажи в жизни и лучше понимать таких людей, а работа руководителя во многом состоит из взаимодействий. Своим опытом всего не получишь. Особенно я люблю нашу классику за это, люди то везде одинаковые, но своих узнавать проще и полезнее в жизни. Научную фантастику я читаю для вдохновения. Интересно смотреть видение и фантазии авторов на развитие мира, на то, чего добьется человечество, а еще обычно там появляется сложная проблема, которую решают не только (и не столько) силовым путем.

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

Волоколамское шоссе. Александр Бек
Что может быть интересно в книге о войне? Если читать в лоб, то только любителям военной литературы. Я бы ее рассматривал с точки зрения управления. Очень хорошо показано, как генерал Панфилов учит своих людей понимать его задумки, думать как он хочет в ситуациях, где его не будет рядом. Показаны проблемы, сопротивление людей и озарения. Показано как это потом спускается ниже. С точки зрения управления и вовлечения в свои идеи очень интересно и жизненно.

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

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

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

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

А что вам особенно запомнилось из прочитанного в 2024 году? Делитесь в комментариях.

Максим Шаламов
#советы #книги #топ2024 #руководителю

Цифровая трансформация

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

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

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

#пнв24 #ПромышленностьНовогоВремени #цифроваятрансформация

Motorsport - симулятор мотогонки

Я сегодня на форуме Промышленность нового времени 2024. Много приехало интересных компаний, в том числе из Белоруссии. Один стенд особо заинтересовал: белорусская компания Motorsport.

Ребята делают не просто VR-симулятор мотоцикла, но и свою платформу полностью имитирующую процесс гонки. Мини-версию платформы засняла для вас на видео. Гонщик не только садится на наклоняющуюся во все стороны платформу, но ещё и надевает костюм, имитирующий усилия и воздействия, то есть можно получить полный спектр ощущений. Обещают даже помочь стресс почувствовать с помощью костюма.

Летом обещают показать первую полностью готовую модель, а к концу 25 года масштабировать собственное производство. Костюм собирают сами.

Главная цель сделать мотоспорт безопасным и более доступным. Открыть сеть школ таких вот виртуальных мотогонщиков по всему миру. Домой в личное пользование сказали не продадут (а я уже размечталась 😢 )

Что думаете о такой идее? Прокатились бы?

#пнв24 #ПромышленностьНовогоВремени #инновации #motorsport #blockchainsports #bcsports

На прошлых выходных выступала с мини-докладом "Заказ и ИТ: история конфликта" на выпускном Школы Спикеров от Деловой Среды. Классный курс, прошла с удовольствием, много пользы и практики. А с вами делюсь записью выступления.

YouTube https://youtu.be/64cJADmeTGg

Дзен: https://dzen.ru/video/watch/67617655ce41010447f547e4

Rutube: https://rutube.ru/video/dcfbe8766e21c3cd1f6fd461ad6585b4/

VK: https://vk.com/wall-215961201_51

Не бросайте лучших сотрудников без внимания

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

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

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

3. В целом, человек тоже может не правильно понять, почему вы не тратите на него время. Даже если вы ему объясните в чем смысл, это ещё не значит, что он с этим согласится. Может создаться впечатление, что вы бегаете от него и не хотите участвовать в его делах. Ведь все равно есть какие-то проблемы, которые без влияния на команду можно обсудить только с руководителем, просто выровняться по своему движению или поговорить, чтобы не терялся контакт. Это все важно и ценно для человека (возможно не для всех, но для большинства).

Старайтесь уделять внимание своим подчинённым вне зависимости от того, справляются они со своими задачи самостоятельно или нет.

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

Максим Шаламов
#руководителю #управлениекомандой #ит #менеджмент

Как бизнесу наладить общение с разработкой. Часть 1

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

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

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

Последовательность действий
Очень важна последовательность ваших действий. Если вы говорите что-то, то выполняете это. Иначе к вашим словам очень быстро перестанут прислушиваться и перестанут обращать внимания на попытки воодушевить команду на новые свершения. Так же к последовательности можно отнести выдерживания минимальных периодов изменения вводных по набору ближайший задач. Хотя бы две недели должны быть нерушимыми (да исключения будут всегда, но это должны быть именно исключительные случаи, которые вы сможете объяснить команде). Я работал в разных сферах и всегда слышал в начале, что две недели никак нельзя терпеть. Но по факту, со временем это переставало вызывать вопросы. Постоянные метания в задачах выбивают вашу команду из фокусировки, оставляют много сделанной в стол работы и влекут накапливающиеся ошибки. В таких условиях эффективно работать могут не многие, а еще меньше людей хочет так работать.

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

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

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

Максим Шаламов
#бизнесу #ит #бизнес #управлениекомандой #разработка #agile

Самые главные проблемы с целеполаганием

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

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

Второе, не менее важное, это совпадение амбиций целей и команды. Например, имея цели держаться на уровне окупаемости, не так просто будет привлечь амбициозную команду. У нас в свое время в Домклик была сформулирована цель как «классифайд по недвижимости №1». Были критерии и во круг этого собралась команда. Все критерии на момент моего ухода достигнуты не были, но по многим был большой прогресс. И главное команду мотивировала эта цель и движение по ней. Важно подбирать команду под цели, иначе вы можете получить неудовлетворительный результат или большую текучку, когда не попадете в ожидания сотрудников.

Максим Шаламов
#руководителю #бизнес #управлениекомандой #разработка #ит #менеджмент

🤖 Живые киборги: Кибер Моторика

На этой неделе в Сколково нас познакомили с компанией Кибер Моторика. Ребята делают очень крутое дело: создают протезы конечностей. Занимаются этим еще с 2013 года и теперь уже выпускают на собственном производстве 250 протезов в месяц. Внедряют распознавание на основе ИИ и разрабатывают новые датчики.

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

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

#интересное #сколково

🔤🔤🔤🔤🔤🔤🔤🔤
Наш проект в преакселлераторе Сколково

На днях наш проект Белая Ворона прошел в преакселлератор Сколково. С вводной встречи поснимала для вас немного на территории технопарка.

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

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

В комментариях пишите про что рассказать в первую очередь ⬇️

Как формируется лидерство: моя история

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

Как я управлял запуском без должности руководителя
Первый свой крупный проект я запускал в Рамблере будучи разработчиком. Тогда мы были в группе RDS с идей быстро запускать и развивать новые направления. Первую версию проекта Путешествий мы сделали меньше чем за месяц, а вот сопровождение всего было все еще частью старой структуры и они еще даже не начали готовить наши сервера. И, в общем, тут бы и сказке конец, ждем и надеемся. Но я обошел все руководство, до которого дотянулся, включая свое направление бизнеса, и мне выдали людей, с которыми мы к 4 часам ночи запустили наш проект. Руководитель, который был в команде, от этой задачи устранился со словами, что лучше подождать. Может лучше, может нет - выбирает каждый сам. Была цель, были найдены возможности, ни должностей ничего тогда у меня не было, лишь умение настаивать на своем. Причем довольно однобоко и топорно на тот момент. Это сейчас уже у меня есть готовый алгоритм, как что-то запустить с помощью ситуационного лидерства, который я описывал в нашем руководстве по борьбе с рутиной, тогда еще я действовал больше интуитивно.

Как я запускал компонент чужого отдела
Следующая интересная история про ситуационное лидерство была в Домклик. Я тогда возглавлял команду оценки недвижимости и нескольких статистических проектов. В один из дней мне поручили пролидировать запуск компонента другой команды, который должен был быть готов к утру следующего дня, но все никак. Общий посыл был, что нужно разобраться и заставить сделать правильно, причем быстро. На вопросы, почему я, получил ответ: "твоего авторитета и знаний хватит, выдай результат". В итоге, я пошел к людям, которые, как выяснилось, знают меня, но которых я особо не знал. Пол дня ушло на понимание в чем проблема и вечер и ночь ушли на то, чтобы проконтролировать, что все будет переделано согласно новой логике (руками в проект я не лез, ни желания, ни возможности не было). Опять же, я был консультантом. Мог ли я сказать, что ничего не выйдет и просто посидеть рядом? Мог. Могло ли случаться, что меня не стали бы слушать? Конечно. Но в этом и есть суть. В такие моменты можно понять готов ты что-то возглавить, а главное не получив ничего взамен (не всегда, но на старте или в моменте так бывает) взять ответственность или нет.

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

Максим Шаламов
#руководителю #разработчику #советы

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

YouTube:
https://youtu.be/1D-MDHeNcTM

Boosty: https://boosty.to/itbesedka/posts/47679e45-272d-40b5-a9f4-9bdf710e1205?share=post_link

Дзен: https://dzen.ru/video/watch/6721d7a040e70a5ac4ac8fed

Рутуб: https://rutube.ru/video/0c925f1d21636e999b0ec23b245c02cb/

VK: https://vk.com/video-215961201_456239046

Как скинуть балласт – избавляемся от нерадивого сотрудника

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

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

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

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

Главное, всегда быть спокойным и конструктивным. Отвечать на вопросы сотрудника, даже если он вам неприятен, и все, вообще все, фиксировать письменном виде.

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

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

Максим Шаламов
#руководителю

Самая недооцененная проблема проекта

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

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

Риски есть повсюду. Не могу придумать ни один проект без рисков. Даже если взять какой-нибудь разрабатываемый вами вечерами проект не связанный с работой, его основные риски это ситуации, в которых у вас не останется на него времени и/или мотивации.
Работаете вы скажем по спринтам и разрабатываете продукт в себе, без интеграций, смежников и прочего головняка. Ну какие тут могут быть риски? Да все, как у всех:

– Текучка кадров
– Болезнь ключевых исполнителей
– Ошибка в оценке сроков, например при создании функционала, который ваша команда до этого не делала
– Выбор неправильного инструмента. Допустим, выбрали вы какую-то библиотеку для ускорения разработки, а оказалось, что вот именно как вам надо она не умеет и либо меняй, либо дорабатывай, - все равно это удар по срокам.
– Или, скажем, проверка безопасности выявит критические проблемы в библиотеках или системах, которые вы используете. Менять или закрывать уязвимости придется и пострадают сроки.

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

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

Максим Шаламов
#риски

Почему задача обязательно должна быть маленькой

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

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

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

Возможность управлять эффективностью
Один из очень важных плюсов маленьких задач - возможность правильно вести статистику работы команды. Если команда работает по итерациям (а вы знаете, что так лучше), то задачи, которые укладываются в итерацию, дают возможность точно посчитать какой объем работы сделала команда (те, кто читал нашу книгу по процессам уже знают, как это делать). Так вы четко следите за снижением и повышением эффективности команды и можете вовремя реагировать на эти изменения. А если команда ушла в работу на 2 или, не дай Бог, 6 месяцев, делая одну задачу, вы по сути останетесь в слепой зоне и узнаете о проблемах в команде уже слишком поздно.

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

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

Александра Шаламова
#agile_который_работает

🧩 Совместимость: как проверить на собеседовании сработается ли кандидат с командой

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

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

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

- какие люди в ней работают, интроверты/экстраверты, веселые, громкие, тихие и т.д.?

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

- как дают обратную связь?

- в каком релизном цикле живут?

- как работают с проблемами, багами, инцидентами?

Только понимая все это, вы сможете оценить впишется ли человек. Например, у меня в командах принято дружеское подшучивание над коллегами и вообще ценится юмор. Если у человека нет определенной самоиронии и спокойного отношения к шуткам, то ему будет крайне сложно адаптироваться. Блокер ли это само по себе для найма - обычно нет (хотя бывают очень плохо воспринимающие любые шутки люди, и для сохранения их нервной системы и нервов команды, стоит по возможности выбрать другого кандидата), но из мелочей должна сложиться картина, подойдете вы друг другу или нет. Хорошим примером может быть форма того, как дается и принимается обратная связь, допустим в моих командах принято давать ОС сразу, четко и прямолинейно (конечно без грубостей и переходов на личности). Как показала практика, не каждый человек готов к такому и не каждый человек хочет настолько прямо получать и давать ОС. Опять же, одна мелочь, но из суммы факторов вы поймете насколько вам по пути.

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

продолжение в следующем посте

⬆️ Что если все еще остались сомнения, совместим ли кандидат с командой

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

Больше о том, как работать с людьми и командой, смотрите в моем учебнике для руководителей технических команд.

Максим Шаламов
#руководителю

♟3 главных урока шахмат: как хобби помогает карьере

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

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

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

Эмоциональная подготовка важна
Третий и очень важный урок, это эмоциональная подготовка, как бы не складывалась ситуация, ты должен держать удар, верить в успех и не давать другим усомниться в себе. На самом деле, я понял это на довольно непримечательной игре, которую тогда выиграл довольно легко. Но легко это было по результату. Девушка с которой я играл просто излучала уверенность в себе. Казалось, что она предвидит каждый ход и я делаю все, что она хочет. В ее случае это привело не со всем к тому, что она хотела. Я полностью собрался и максимально долго обдумывал каждый ход. В итоге игра шла часа 2, но я до сих пор помню тот эффект, который вызывало ее поведение.

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

Максим Шаламов
#советы

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

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

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

А что на практике?
Многие, получив самостоятельность, все равно бегают по каждой сложной ситуации к руководителю или «радуют» тем, что задача не будет сделана в срок в последний момент. Поэтому эксперименты со свободой быстро заканчиваются.

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

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

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

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

Максим Шаламов
#руководителю

Почему ты вечно все узнаешь последним?

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

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

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

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

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

Как правильно говорить о рефакторинге с бизнесом со стороны IT команды

Инициаторами рефакторинга должна быть IT команда, поэтому ее задача первым же делом инициировать сбор метрик на проекте, если они по какой-то причине не ведутся (а ведь они могли бы помочь раньше увидеть проблемы и не допускать тяжелой ситуации на проекте). Дальше нужно смотреть динамику этих метрик (например, рост числа багов, рост времени починки багов и т.д), вы должны увидеть, как ухудшается ваш проект в реальных значениях. После этого IT команда должна встретится с бизнес командой и обсудить с ними эти метрики и их изменение, узнать (если еще не узнали) рост каких метрик для бизнеса критичен и насколько (обычно говорят о t2m и багах). После чего нужно представить свой план рефакторинга, в котором обязательно должны быть:

- сроки. Без сроков на рефакторинг нет смысла даже начинать разговор;

- ресурсы. То есть, что и кто вам нужен для рефакторинга;

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

- на какие метрики и как повлияют работы по рефакторингу;

- какие запланированные шаги.

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

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

Как решить стоит ли переписывать проект?

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

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

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

Метрики, как обязательная составляющая рефакторинга
Первое, что вам нужно сделать, когда вы начали обсуждать изменения в проекте - определить и настроить метрики. Нельзя подходить к вопросу о глобальном рефакторинге или отказе от него без метрик. Метрики могут быть, как влияющими на бизнес на прямую, например баги, t2m и скорость работы проекта. Так и косвенно влияющие на бизнес составляющую: скорость погружения сотрудников в проект, количество человек владеющих кодовой базой, уровень дублирования кода (а порой и сервисов), количество возвратов PR (пулл реквестов) и т.д. На самом деле, все эти метрики влияют на качество продукта. Те, что кажутся косвенными, обычно приводят к большой текучке и вымыванию сильных разработчиков из команды, что замедляет выпуск нового функционала и напрямую влияет на отказоустойчивость и общее качество продукта.

Именно метрики помогут вам понять и необходимость рефакторинга на проекте и то, насколько удачным получился результат. Также не забывайте в процессе отслеживать метрики работы команды, чтобы понимать насколько удачно проходят работы и движетесь ли вы с нужной скоростью. Подробной работе с метриками команды вы можете научиться с помощью нашей книги "Гибкие методологии на практике". Такое умение пригодится вам и в любое другое время работы над проектом. Это вообще обязательные знания для любого, кто работает с ИТ-проектами.

Полная переделка проекта - камень преткновения на старых проектах

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

Почему разработка все время хочет все переписать
Сразу развеем один распространенный миф. Среди многих бизнес команд бытует мнение, что IT команде совсем не интересен продукт, - это не так. Все любят делать проект для людей, чтобы им пользовались и чтобы он приносил пользу. Ничего так не демотивирует команду, как задачи сделанные “в стол”.

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

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

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

Почему бизнес сопротивляется
Бизнес при этом не видит каждый день тех проблем в коде, которые видит разработка. У него все идет, как обычно, возможно задачи стали делаться чуть дольше, возможно ошибок на проекте стало больше, может немного текучка разработки увеличилась, но это все бывает и по другим причинам. Однако, чаще всего, сам продукт работает, как обычно (если проблемы с кодом не сказываются на производительности проекта). Он приносит деньги, приходят пользователи, клиенты, идут продажи. Есть много планов на будущее, которые хочется реализовать. А самое главное, есть конкуренты, которые постоянно дышат в затылок и стараются обойти.

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

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

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

Как я облажалась в описании задачи

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

Итак, приложение с прохождением чего-то вроде опросника, где динамически меняются вопросы в зависимости от ответов пользователя. Дизайнер нарисовал внизу классическую нумерацию шагов "шаг 3/6", мне показалось это логичным, поэтому я внесла это в ТЗ. Во время разработки мне пишет менеджер с просьбой внести в АПИ количество вопросов в каждом опроснике. Я начинаю объяснять, что количество вопросов динамическое и зависит от ответов пользователя. На что он мне присылает этот скриншот с комментарием, что посчитать финальное количество шагов в динамическом опросе невозможно 🤦🏼‍♀️

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

А какие у вас были недочеты в описании задач? Забывали что-нибудь критичное? Или вам приходил запрос сделать что-то невозможное? Делитесь в комментариях.

Александра Шаламова

Почему разработчики задают столько вопросов

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

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

Я уже говорила, что разработка иначе смотрит на систему, потому что у нее другой набор знаний, более глубокий в технической области. И даже разработчики из другой сферы не смогут предсказать многие проблемы во время разработки в незнакомой им среде. И даже в чужом проекте на тех же технологиях. Везде есть своя специфика. Разработчик, смотря на задачу, видит вопросы более глубокие, касающиеся реализации и технических нюансов разработки. Этой информации просто не может быть в изначальном описании задачи. Автор просто не знает таких нюансов. Так что же получается, невозможно избавиться от постоянных, бесконтрольных вопросов во время разработки?

Здесь вам на помощь приходят процессы. Не просто так в большинстве компаний есть регулярные встречи по уточнению бэклога и оценке. Именно они помогают бизнесу дополнить описания задач с участием разработки, чтобы заранее, в специально отведенное для этого время, решить все вопросы разработки и доработать задачи с учетом этих вопросов. Как проводить такие встречи мы подробно разбираем в нашей книге по построению процессов работы команды "Гибкие методологии на практике". Научившись правильно работать по этим процессам, вы освободите свое время и до минимума сократите количество потока бесконечных вопросов от команды.

Александра Шаламова
#agile_который_работает

Должны ли все сотрудники мыслить, как руководитель?

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

Но чтобы это работало, нужно учесть несколько важных моментов.

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

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

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

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

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

Максим Шаламов
#руководителю

А сами исполнители умеют описывать задачи?

Я заикнулась в прошлый раз, что разработке, да и любым исполнителям или тем, кто когда-то работал исполнителем, может казаться, что они на отлично умеют описывать задачи, потому что постоянно сталкиваются с проблемами в описании задач и знают, что нужно. А вот как бы не так!

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

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

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

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

Александра Шаламова
#agile_который_работает

Как я не позволял подчиненным совершать ошибки и что из этого вышло

Откуда идет большая часть желания все проверить или сделать за своих сотрудников? От страха ошибки. Особенно это распространено у начинающих руководителей, но кто-то живет с этим всю свою карьеру. Вы боитесь ошибок своих людей, потому что считаете это своей ошибкой. Но даже если этот страх преодолевается, дальше идет череда ситуаций пока люди учатся и набираются опыта. Они ошибаются и ошибаются часто, поэтому соблазн сделать что-то за них слишком велик. И в краткосрочной перспективе это дает вам результат. Многие удивляются, я же сделал, задача решена в чем проблема? А проблема в том, что ошибки учат людей лучше всего. Это самый яркий и ценный опыт. Лишая его, вы забираете у людей самый лучший способ учиться. Второе следствие ваших действия это то, что люди будут терять веру в себя и мотивацию что-то делать. Никому не нравится, когда за каждым шагом следят и не дают развернуться. Так же люди привыкают, что проблемы за них решат и подстрахуют, и со временем на вас будет все больше и больше работы.

На самом деле очевидно, что не всегда можно дать ошибиться, где-то цена ошибки слишком велика. Или действие новое для всех и вы все вместе учитесь и решаете проблемы. Поиск баланса происходит постоянно. Работая техдиректором в ТАСС, я тоже понял, что слишком опекал свою команду и мои лиды не понимали реалии работы в компании и много где не могли помочь. Со временем слишком много текучки скопилось в одних руках и это стало огромной проблемой, не только в плане скорости работы, но и в собственной мотивации заниматься этим. Поэтому вкладываясь в рост команды, давая ошибаться вы решаете свою проблему, проблему того, что все решения и вся рутина упадут на вас и вы просто не сможете или не захотите этим всем заниматься.

Больше о том, как правильно работать с командой, ищите в нашем учебнике для руководителей.

Максим Шаламов
#руководителю

Даже те, кто отлично пишет постановку задач, забывает об этом

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

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

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

Александра Шаламова
#agile_который_работает

Руководители команд получают, как разработчики, тогда зачем вообще весь этот головняк?

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

Так и зачем тогда вообще разработчику идти в руководители? Лично для меня основной ответ один: ты начинаешь влиять на все большее количество вещей. Да, я помню то удовольствие, которое получал, сделав целый сервис за несколько дней и он сразу начал приносить пользу пользователям и компании. Но теперь я могу повлиять на то, чтобы работали куда более масштабные проекты, они росли и приносили пользу людям и компании. Я могу собирать команды и людей, с которыми мне нравится работать, в которых мне интересно вкладываться и которые помогают мне расти. Ты видишь больше возможностей, доверия, но и ответственности. Это для меня самое главное в работе руководителя.

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

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

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

Максим Шаламов
#разработчику #руководителю

Почему тяжело описывать задачи

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

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

Как пример, заказчик хочет сделать кнопку подписки. У него в голове есть только это действие, ему нужно, чтобы человек подписался. Он наверное делал это сам когда-нибудь, но он даже не помнит, что там в интерфейсе происходило - нажал и забыл. Какая там валидация у поля, какие сообщения об успехе или ошибке могут быть, нужна ли галочка "согласен на обработку данных" и так далее. Это все просто не приходит в голову, потому что с этой стороны систему ты не знаешь. И это совершенно нормально! У каждого своя сфера, в которой он максимально силен.

В итоге заказчику ясно одно "я хочу кнопку подписаться" - все! И многие задачи на разработку именно так и выглядят. Одна фраза "сделай название фичи". А у разработчика при первом же взгляде на эту задачу появляется уйма вопросов.

Что можно сделать, если вы совсем не знаете, как поставить задачу и с чего вообще начать, мы описали в первой главе руководства. Пользуйтесь сами и делитесь со своими заказчиками. Кстати, не думайте, что если вы по задачам все время работаете, то вы сами умеете задачи описывать. Я тут недавно в очередной раз писала ТЗ для проекта, десять раз ловина себя на "ну это же очевидно". Но это уже совсем другая история.

Александра Шаламова
#agile_который_работает