20 лет опыта управления IT-проектами. Как работает mind-set сеньора и как изменить свое понимание задач?

Я занимаю руководящую должность вот уже более 20 лет и не раз видел, как неправильное понимание сути задачи приводит к существенным потерям времени. Что уж говорить, бывало, и я тратил месяцы своей жизни на то, что потом оказывалось ненужным только потому, что я не задал всего лишь один важный вопрос в самом начале проекта. Куча проблем, внутреннее недовольство собой и впустую потраченное время, потому что не поняли сути и не задали правильный вопрос из серии «За что боремся?».

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

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

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

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

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

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

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

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

Представим ситуацию. Ваш продакт-менеджер присылает гневное сообщение: «У нас проблема с производительностью, ничего не работает!». Можно вместе с ним начинать посыпать голову пеплом, а можно начать задавать вопросы. «Почему ты решил, что ничего не работает?» Уже на первом вопросе выясняется, что коллега посмотрел только одну страничку и не работает только она. Дальше — больше: чем чаще звучит вопрос «почему», тем более ясной становится картина действительности.

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

Понимание сути — это ключевой навык для толкового разработчика. Рассмотрим классическое противостояние frontend и backend. Фронт просит поменять что-то в API (DateTime на TimeSpan). Почему? Да потому что так надо, без объяснений. Бэк, в свою очередь, не задает лишних вопросов и не старается уловить суть, просто делает то, что просят.

Какие возможны последствия? Фронтенд понятия не имеет, что бэку нужно учитывать такие вещи, как версионность и совместимость. Мобильное приложение перестало работать, контракты отвалились.

Как нужно было поступить? Фронтенд объясняет проблему и рассказывает о своей боли. Например: «Хочу выводить данные в другом виде. Что можно сделать?» Бэкенд понимает суть задачи и предлагает рабочие варианты. Все счастливы, проблем не возникает.

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

Если не понимаете сути, задавайте вопросы, а если понимаете — не бойтесь предлагать варианты.

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