В последнее время я мало пишу код, в основном работаю с людьми. Веду также домашние проекты, где все еще программирую, но на работе занимаюсь другими делами. Я объясняю, что сделать, а если задача сложная или относится к архитектурным решениям, то ещё и объясню, как это сделать. По большому счету это обычная работа руководителем, хотя и со своей спецификой.
Ещё много приходится заниматься аналитикой, т.е. проработкой и уточнением бизнес логики и требований. Наши заказчики не всегда их детализируют, часто задача приходит в самом общем виде, в виде пары тройки абзацев. Вдумайтесь, первоначальные требования к проекту на десятки, а то и сотни тысяч долларов сформулированы в двух-трех абзацах на одном листе бумаги формата A4.
Возможно, это специфика нашей компании, у которой на входе много стартапов и много заказчиков, слабо знакомых с особенностями программной разработки, но что-то мне подсказывает, что это не такое уж и редкое явление. Понятно, что по ходу дела эти требования проясняются и дополняются, но изначально, как правило, задача плохо формализована и ожидаемое поведение системы описывается приблизительно. В итоге это порождает некоторый сумбур и хаос, особенно в начале проекта. Не могу удержатся от этой картинки.
Мы по центру)
Еще я часто занимаюсь разработкой интерфейсов, т.е. меня привлекают к таким обсуждениям, на которых прорабатывают интерфейсные элементы: где и какие будет кнопки, таблицы, селекты, как они должны быть сгруппированы, на каких экранных они будут и какие экраны будут в принципе. Обычно я выступаю в роли эксперта/консультанта, раздаю ЦУ и объясню, какую логику должен отработать тот или иной интерфейс. К счастью отрисовывать макеты интерфейса мне не нужно, этим занимаются другие люди, но все равно времени и сил это отнимает изрядно.
Зачем я этим занимаюсь? Вроде бы не совсем моя тема. Отчасти это связано с тем, что у меня хороший опыт по построению всевозможных интерфейсов и я могу оценить насколько он адекватен/удобен. Отчасти это связано со спецификой разработки, как правило, бэкэнд разработчики просто больше всех знают. Знают в том смысле, что на уровне бэкенда принимается много важных решений, связанных с логикой системы, ее данными, зависимостями и др. В итоге обычно фронтенд разработчики приходят к нам и спрашивают, как должно быть, а не наоборот. И зачастую именно бэкенд оценивает и одобряет итоговый интерфейс или инициирует в нем изменения из-за того, что логика отражена не совсем корректно.
Не могу утверждать, что именно так и должно быть, но в нашей компании это так. И еще это так, потому что я готов и считаю необходимым этим заниматься. Зачастую это моя добрая воля: вникать в самые разные дела, связанные с проектом и способствовать его продвижению. Лично мне важно, чтобы проект был сделан по уму, чтобы на выходе получился хороший результат.
Я мог бы отстраниться от этого и сказать, что за это отвечает PM (project manager), он у нас есть и формально это его зона ответственности, но в жизни все немного сложнее и не всегда формальные обязанности совпадают с реальной ответственностью. В общем это отдельный разговор и речь сейчас не об этом. В итоге лично на меня всё это накладывает некоторые обязательства и порождает множество ситуаций, связанных с принятием решений.
Если говорить более конкретно, то моя текущая должность называется тимлид (от англ. team leader) или более официально «руководитель группы разработчиков». Помимо самого руководства я также отвечаю за архитектуру проекта, качество кода, а также выбор тех или иных решений в процессе разработки, причём решений не только технического плана, но, как вы уже поняли, и решений, относящихся к логике проекта.
В общем по смыслу это лидерская позиция, т.е. в меру своих сил и способностей я веду за собой людей. Не скажу, что это уж совсем какой-то уникальный опыт, так или иначе всё это уже было. Вопрос только, как часто или как много приходилось выступать в этой роли. Сейчас это составляет большую часть моей профессиональной деятельности.
Имеет ли значение тот факт, что у меня есть ресурс власти? Конечно, да. Я вправе принимать те решения, которые сочту необходимыми. Я могу навязать своё решение и заставить других сделать то, что я считаю правильным. Редко, но к этому иногда тоже приходится прибегать. Это не очень конструктивно и скорее свидетельствует о моем неумении найти нужные аргументы. Однако чаще всего моего авторитета хватает, чтобы убедить коллег, не включая режим диктатора.
И вот здесь-то и начинается самое интересное. Казалось бы, все хорошо, коллеги доверяют моему мнению, соглашаются с ним и делают именно то, что нужно. А как насчёт ошибок, они могут быть? Конечно, могут и я так же как любой другой человек иногда ошибаюсь. Только в отличие от ошибок других людей, мои ошибки могут обойтись существенно дороже. Какое-нибудь сомнительное решение, принятое на старте проекта может привести к большим и серьёзным проблемам спустя несколько месяцев. Что в свою очередь может привести с срыву сроков, демотивации команды и др. неприятным последствиям. Совсем уж фатальных ошибок у меня не было, но случались, конечно, и не самые удачные решения, за которые тоже приходилось «платить по счетам».
К чему я это все веду? Ну ошибся и ошибся – бывает. Проблема не в самой ошибке и даже не в последствиях, проблема в том, что многих ошибочных решений можно избежать, просто внимательно выслушав коллег. И все, что для этого требуется – дать им возможность высказаться. Как минимум, не мешать озвучивать свои мысли и соображения, как максимум, стимулировать высказываться. Среди таких высказываний может быть много странных и очевидно ошибочных мнений, но это тоже ценно. Сам факт того, что тебя слушают, принимают во внимание твоё мнение – важен. Даже если потом эти мнения будут отброшены и вы примите то, что сами придумали, тем не менее вы сможете выбирать из нескольких вариантов, в том числе и из тех, которые просто не пришли вам в голову.
Может так оказаться, что ваше решение вполне приемлемо, но не идеально, а высказанная кем-то мысль позволит довести его до ума. Сама возможность взглянуть на проблему с разных точек зрения, которые вам озвучат коллеги – она дорогого стоит.
Так почему же с этим возникают проблемы? Конечно, я не могу говорить за всех, у всех с этим по-разному, но я точно попадал в такие ситуации, когда фактически отсекал очень интересные и перспективные варианты. Иногда удавалось понять это спустя какое-то время после разговора. Я понимал, что поторопился, а то решение, которое пытался озвучить условный Вася – оно лучше. Если такое случалось, я возвращался к обсуждению, снова выслушивал Васю, отменял своё решение и принимал другое. А сколько я пропустил таких осознаний?)
Проблема здесь не столько в нежелании слушать, сколько в доминировании лидерского подхода: раз я лидер и я веду за собой людей, то мне и решения предлагать, но это ошибочное мнение. Конечно, вы можете предлагать идеи, но они не должны изначально стоять выше идей, озвученных коллегами, т.е. не нужно давить авторитетом на этапе обсуждения возможных решений. Лучше вообще не торопиться со своими предложениями, чтобы не подавлять активность других участников обсуждения.
Каждая озвученная идея, каждый предложенный вариант от участников команды – он важен и он может оказаться лучше, чем то, что вы придумали сами. Он может оказаться лучшим вариантом сразу или после небольшой доработки, шлифовки.
В общем задача лидера не в том, чтобы предлагать решения. Хотя иногда без этого не обойтись и в сложных случаях именно вам придётся их генерировать, но это все же не главное. Основная задача – выбрать наилучшее решение, принять его и воплотить в жизнь. Иногда для этого приходится задвигать своё мнение. Есть хороший призыв на этот счёт: «оставьте своё эго за дверью» («leave your ego at the door»). Зачастую именно оно и мешает.
А что там с ловушкой, про которую упоминалось в заголовке? А с ловушкой все просто, фактически мы уже её проговорили. Проявляется она в неумении или нежелании выслушивать чужие мнения, предложения, идеи. А причиной её возникновения может служить
- банальная спешка: быстрей-быстрей, нужно срочно принять решение;
- чувство собственной важности: я же лид, опытный и знающий специалист, моё мнение куда ценнее и важнее мнения других людей;
- плохо налаженная коммуникация с коллегами, т.е. не организован, не налажен сбор мнений, у людей нет возможности или стимула их высказывать;
- ошибочное понимание роли лидера: цель не в том, чтобы самому предложить наилучшее решение, цель в том, чтобы выбрать наилучшее решение из предложенных.
На этом я, пожалуй, закончу. Тема лидерства обширна и здесь ещё много чего можно обсудить, но это уже в другой раз.
Валерий Чугреев, 19.12.2020
