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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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