Как правильно принимать решение

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

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

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

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

Ключевые моменты для правильного принятия решения
Что я считаю критично для принятия решений:

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

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

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

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

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

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

Алгоритм подготовки и проведения любой встречи

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

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

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

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

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

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

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

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

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

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

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

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

Как не погрязнуть в ручных правках

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

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

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

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

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

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

Нужны ли руководителю технические знания?

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

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

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

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

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

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

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

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

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

#тимлиду #разработчику

Как я следовал своим же советам и что из этого вышло

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

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

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

Стоило ли оно того?
В итоге, по прошествии полугода, я прошел через самый сложный релиз из всех, что у меня был (хотя каждый раз думаешь, ну куда уж хуже=)) ), работаю с людьми, с которыми хотел работать, работаю с бизнесом, который хочет результат, а не иллюзию контроля. Если говорить про всякие числовые показатели, люди, команды и т.д, то тут тоже произошел шаг вперед. Это не история про то, как все идеально и лучше быть не может. Нет, проблемы есть и их много, но сейчас есть возможности для их решения, что самое главное для меня, понятны зоны и возможности роста.

Что могу сказать в виде итога для вас:

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

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

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

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

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

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

Как выбрать коллег, увлеченных своим делом, на собеседовании

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

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

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

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

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

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

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

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

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

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

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

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

Начнем с того, что большинство топовых ИТ-компаний работают по гибким методологиям. Сюда войдут и Google, и Microsoft, и Яндекс и многие многие другие. О плюсах их использования для бизнеса мы уже не раз говорили. Гибкие методологии в своей основе предполагают ежедневное общение представителей бизнеса и разработки. Лично разработки, не через руководителя. Эти методологии и называются та гибкими, потому что именно такое взаимодействие позволяет продукту стать гибким, увеличивает скорость отклика на нужды бизнеса. Итак, для бизнеса это плюс, это проверено множеством компаний на практике.

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

Вот кратко наше мнение по этому поводу. Подробнее обо всем этом мы писали в мини-курсе, он доступен на нашем сайте.

А что думаете вы? Ждем ваше мнение в комментариях.