Фокусировка - держим команду в фокусе

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

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

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

Расставьте приоритеты
Говоря про большие релизы, нужно сформировать не только цель, но и четко приоритезировать все задачи, связанные с целью. Приоритезация будет нужна, потому что в больших релизах от части запланированного функционала придется отказаться. Я рекомендую всегда уменьшать функционал, а не двигать сроки. Это позволяет минимально работать в стол и максимально быстро получить обратную связь от пользователей и понять идет ли все по плану или нет. Сдвиги сроков обычно сильно давят на команду и чем дальше, тем будет становиться хуже. Мое мнение на этот вопрос однозначное: ваша задача к дедлайну иметь работающий и отлаженный проект с набором критичного функционала. Очень важно, что работающего и отлаженного функционала, в который можно пускать пользователей. Тогда можно уже обсуждать в деталях, есть ли смысл в том, что получилось, и какой приоритет у доработок и следующих шагов. Если же вы приходите к дедлайну с набором недоделанных фичей, то ни о каком запуске речи быть не может, как и об успешной работе над взятым функционалом.

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


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

Максим Шаламов
#тимлиду #agile_который_работает

Кто должен быть лидером в команде разработки

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

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

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

Как должно быть?
Однако, я считаю, что в эффективной команде (опять же в жизни бывает всякое) лидером должен быть именно тимлид. Потому что тимлид должен думать о команде, качестве продукта, поддерживаемости и так далее. Это как минимум часть его работы, причем существенная. Тимлид должен балансировать ПО и его неуемное желание бежать вперед.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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