Трудности ИТ-перевода
Как повысить качество создаваемых программных решений при взаимодействии ИТ-специалистов и руководителей организаций
Управление разработкой может быть очень непростым процессом, полным парадоксов и скрытых возможностей. О том, что может тормозить рабочие процессы и как избежать типичных проблем при взаимодействии ИТ-специалистов, их руководства и бизнеса, читателям RSpectr рассказал ведущий инженер-программист финансового маркетплейса «Выберу.ру» Роман Сыроешкин.
ПЕРЕВОДЧИК МЕЖДУ БИЗНЕСОМ И РАЗРАБОТКОЙ
Сталкиваясь с логикой разработчика, человек из бизнеса может подумать, что программированием занимаются очень странные люди. Когда талантливому специалисту ставят задачу, он на нее иногда смотрит как робот. Порой решение программиста способно удивить заказчика: бывает, что оно все портит с точки зрения бизнеса, но зато разработчику было интересно это создать и решить занятные головоломки.
Чтобы решить эту проблему, между бизнесом и ИТ-специалистами должен встать человек, который будет переводить информацию на понятный для каждой стороны язык. Кому-то придется учиться быть на стыке этих двух миров, чтобы просто транслировать задачи и обдумывать, как их лучше выполнять. Именно он будет контролировать, какие цели нужно достичь, чтобы бизнес был ими доволен. Найти такого человека – настоящая проблема.
Если разработчики не понимают потребностей бизнеса, то руководители не знают, на что способна разработка
Часто заказчик имеет ограниченное представление о технических возможностях своего же сайта или приложения. Когда представитель бизнеса ставит задачу собрать какие-то данные, чтобы проанализировать их и решить, в какую сторону развивать бизнес, он и не предполагает, что разработка может собрать и другие данные, с которыми выводы будут точнее.
То же самое касается функционала. Например, на сайте есть десять рекламных баннеров на разные темы – от кошачьего корма до палаток, и они показываются всем посетителям без разбора, вместо того чтобы демонстрироваться каждому с учетом потребностей. Заказчик просто не знает, что сайт собирает данные о посетителях и умеет различать их по интересам, а потому даже не ставит таких задач.
МУЧИТЕЛЬНЫЕ ДУМЫ И ТИХИЕ МАТЕМАТИКИ
Разработчики обычно имеют глубокую экспертизу в своем направлении, но при этом мало что понимают в других сферах. Разбираться во всем просто невозможно, тем более когда речь идет о сложных технических знаниях и навыках. Отсюда вытекает интересный парадокс – пока один специалист целый день ищет решение, будучи ограниченным своей областью знаний, другой может просто подумать и сразу найти ответ.
В среде общительных людей это не будет проблемой – один спросит, другой подскажет. Однако у программистов все иначе. Здесь тот, кто имеет достаточно знаний и понимает, как решить задачу, может оказаться крайне нелюдимым. Он может не идти на контакт и не любить высказывать свое мнение. Это следует иметь в виду – знать, что среди команды может найтись человек, для которого проблема легко решаема, но не ждать, пока он придет с решением сам, а спросить, желательно письменно, чтобы не вызывать психологического дискомфорта от общения тет-а-тет.
МОНОТОННОСТЬ УБИВАЕТ ЭФФЕКТИВНОСТЬ
Несмотря на то что программисты своей логикой порой похожи на роботов, они ровно так же подвержены выгоранию от рутинных повторяющихся задач, как и люди любых других профессий. Все время заниматься решением одних и тех же проблем скучно. Монотонность выматывает, и это не всегда видно снаружи. Выгорание выражается в том, что разработчик просто не может выполнять свою работу: раньше справлялся за заложенное время, а теперь при тех же задачах производительность труда падает. Описать в такой ситуации свое состояние он сам не может, руководителю приходится проявлять проницательность.
У нас во избежание этой проблемы люди разбиваются на команды, и специалисты могут переходить из одних в другие, меняя направление. Иногда человек явно высказывает желание перейти, а иногда он просто вдруг начинает жаловаться на все подряд. Если обвинить человека в этот момент в лени, он просто уйдет в другое место. Ошибка думать, что человек перетерпит скуку и успокоится, лучше перевести его на другие задачи. На собеседовании мы спрашиваем у людей, куда они хотят двигаться. В данном случае или, если сотруднику скучно, им также можно подбирать обучающие курсы.
Нередко менеджер думает, что может поймать программиста и задать все вопросы, при этом чем быстрее он их все задаст, тем будет проще. Когда программист делает мелкие задачки, это действительно так – он может остановиться, ответить и спокойно продолжить работу. А вот если задача большая и сложная, то, когда кто-то приходит, вырывает из контекста, задает вопросы и заставляет думать про что-то другое, это вмешательство обходится дороже.
Разработчику в итоге нужно заново тратить время на погружение в свою сложную задачу.
Возможность всегда быстро спросить что-то у исполнителя приводит к тому, что ответы он дает, но свою задачу выполнять не может
При приближении дедлайнов это самый верный способ их сорвать.
Чтобы задавать вопросы, нужно подбирать для них время. Лучше всего задавать их на утреннем «созвоне»-совещании, когда всей командой обсуждается, кто что делает, есть ли какие-то проблемы, кто может помочь, и дальше не отвлекать разработчиков. Для уточнения текущего статуса задач всегда есть доска, на которой сотрудники отмечают, над чем работают, а что закончили. Понятно, что вопросы все равно могут возникать, но их лучше задать «тимлиду», а не отрывать разработчика от мыслительного процесса. Иначе это будет лишь тормозить процесс, как постоянное открывание крышки при попытке быстро вскипятить воду в кастрюле.
