1. Переводчик между бизнесом и разработкой
Сталкиваясь с логикой разработчика, человек из бизнеса может подумать, что программированием занимаются очень странные люди. Когда талантливому специалисту ставят задачу, он на нее иногда смотрит как робот. Порой решение программиста способно удивить заказчика: бывает, что оно все портит с точки зрения бизнеса, но зато программисту было интересно это запрограммировать и решить интересные головоломки.
Чтобы решить эту проблему, между бизнесом и разработкой должен встать человек, который будет переводить информацию, на понятный для каждой стороны язык. Кому-то придется учиться быть на стыке этих двух миров, чтобы просто транслировать задачи, и обдумывать, как их лучше выполнять. Именно он будет контролировать, какие цели нужно достичь, чтобы бизнес был ими доволен. Найти такого человека реальная проблема.
2. Скрытые возможности
Если разработчики не понимают потребностей бизнеса, то бизнес не знает на что способна разработка. Часто заказчик имеет ограниченное представление о технических возможностях своего же сайта или приложения. Когда представитель бизнеса ставит задачу собрать какие-то данные, чтобы проанализировать их и решить в какую сторону развивать бизнес, он и не предполагает, что разработка может собрать и другие данные, с которыми выводы будут точнее. То же самое касается функционала. Например, на сайте есть десять рекламных баннеров на разные темы от кошачьего корма до палаток, и они показываются всем посетителям без разбора, вместо того, чтобы демонстрироваться каждому с учетом их потребностей. Заказчик просто не знает, что сайт собирает данные о посетителях и умеет отличать их по интересам, а потому даже не ставит таких задач.
3. Мучительные думы и тихие математики
Разработчики обычно имеют глубокую экспертизу в своем направлении, но при этом мало что понимают в других. Разбираться во всем просто невозможно, тем более, когда речь идет о сложных технических знаниях и навыках. Отсюда вытекает интересный парадокс — пока один специалист целый день ищет решение, будучи ограниченным своей областью знаний, другой может просто подумать и сразу найти ответ. В среде общительных людей это не будет проблемой — один спросит, другой подскажет. Однако у программистов все иначе. Здесь тот, кто имеет достаточно знаний и понимает, как решить задачу, может оказаться крайне нелюдимым. Он может не идти на контакт и не любить высказывать свое мнение. Это следует иметь в виду — знать, что среди команды может найтись человек, для которого проблема легко решаема, но не ждать, пока он придет с решением сам, а спросить самому, желательно, письменно, чтобы не вызывать психологического дискомфорта от общения tet-a-tet.
4. Монотонность убивает эффективность
Несмотря на то, что программисты своей логикой порой похожи на роботов, они ровно так же подвержены выгоранию от рутинных повторяющихся задач, как и люди любых других профессий. Все время заниматься решением одних и тех же проблем скучно. Монотонность выматывает и это не всегда видно снаружи. Выгорание выражается в том, что разработчик просто не может выполнять свою работу: раньше справлялся за заложенное время, а теперь при тех же задачах производительность труда падает. Описать в такой ситуации свое состояние он сам не может, руководителю приходится самому проявлять проницательность.
У нас во избежание этой проблемы люди бьются на команды, и специалисты могут переходить из одних в другие, меняя направление. Иногда человек явно высказывает желание перейти, а иногда он просто вдруг начинает жаловаться на все подряд. Если обвинить человека в этот момент в лени, он просто уйдет в другое место. Ошибка думать, что человек перетерпит скуку и успокоится, лучше перевести его на другие задачи. На собеседовании мы спрашиваем у людей, куда они хотят двигаться. В данном случае или, если сотруднику скучно, им также можно подбирать обучающие курсы.
5. Вред быстрых расспросов
Нередко менеджер думает, что может поймать программиста и задать все вопросы, при этом, чем быстрее он их все задаст, тем будет проще. Когда программист делает мелкие задачки, это действительно так — он может остановиться, ответить и спокойно продолжить работу. А вот если задача большая и сложная, то когда кто-то приходит, вырывает из контекста, задает вопросы и заставляет думать про что-то другое, это вмешательство обходится дороже. Разработчику в итоге нужно заново тратить время на погружение в свою сложную задачу. Возможность всегда быстро спросить что-то у исполнителя приводит к тому, что ответы он дает, но свою задачу выполнять не может. При приближении дедлайнов это самый верный способ их сорвать.
Чтобы задавать вопросы, нужно подбирать для них время. Лучше всего задавать их на утреннем созвоне. На звонке всей командой обсудить, кто что делает, есть ли какие-то проблемы, кто может помочь и дальше не отвлекать разработчиков. Для уточнения текущего статуса задач всегда есть доска, на которой сотрудники отмечают, над чем работают, а что закончили. Понятно, что вопросы все равно могут возникать, но их лучше задать тимлиду, а не прерывать разработчика от мыслительного процесса. Иначе это будет лишь тормозить процесс, как постоянное открывание крышки при попытке быстро вскипятить воду в кастрюле.