IT-беседка

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

Послушала сессию по цифровой трансформации на форуме ПНВ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 важных пункта. А если не получается наладить общение, то приходите к нам на консультацию, разберём вашу ситуацию и поможем найти решение.

Максим Шаламов
#бизнесу

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

Проходя очередной цикл бюджетного и проектного планирования на год, не мог в очередной раз не задуматься о целеполагании. Да, сейчас можно много чего почитать про 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_который_работает