1. Переводчик между бизнесом и разработкой
Сталкиваясь с логикой разработчика, человек из бизнеса может подумать, что программированием занимаются очень странные люди. Когда талантливому специалисту ставят задачу, он на нее иногда смотрит как робот. Порой решение программиста способно удивить заказчика: бывает, что оно все портит с точки зрения бизнеса, но зато программисту было интересно это запрограммировать и решить интересные головоломки.
Чтобы решить эту проблему, между бизнесом и разработкой должен встать человек, который будет переводить информацию, на понятный для каждой стороны язык. Кому-то придется учиться быть на стыке этих двух миров, чтобы просто транслировать задачи, и обдумывать, как их лучше выполнять. Именно он будет контролировать, какие цели нужно достичь, чтобы бизнес был ими доволен. Найти такого человека реальная проблема.
2. Скрытые возможности
Если разработчики не понимают потребностей бизнеса, то бизнес не знает на что способна разработка. Часто заказчик имеет ограниченное представление о технических возможностях своего же сайта или приложения. Когда представитель бизнеса ставит задачу собрать какие-то данные, чтобы проанализировать их и решить в какую сторону развивать бизнес, он и не предполагает, что разработка может собрать и другие данные, с которыми выводы будут точнее. То же самое касается функционала. Например, на сайте есть десять рекламных баннеров на разные темы от кошачьего корма до палаток, и они показываются всем посетителям без разбора, вместо того, чтобы демонстрироваться каждому с учетом их потребностей. Заказчик просто не знает, что сайт собирает данные о посетителях и умеет отличать их по интересам, а потому даже не ставит таких задач.
3. Мучительные думы и тихие математики
Разработчики обычно имеют глубокую экспертизу в своем направлении, но при этом мало что понимают в других. Разбираться во всем просто невозможно, тем более, когда речь идет о сложных технических знаниях и навыках. Отсюда вытекает интересный парадокс — пока один специалист целый день ищет решение, будучи ограниченным своей областью знаний, другой может просто подумать и сразу найти ответ. В среде общительных людей это не будет проблемой — один спросит, другой подскажет. Однако у программистов все иначе. Здесь тот, кто имеет достаточно знаний и понимает, как решить задачу, может оказаться крайне нелюдимым. Он может не идти на контакт и не любить высказывать свое мнение. Это следует иметь в виду — знать, что среди команды может найтись человек, для которого проблема легко решаема, но не ждать, пока он придет с решением сам, а спросить самому, желательно, письменно, чтобы не вызывать психологического дискомфорта от общения tet-a-tet.
4. Монотонность убивает эффективность
Несмотря на то, что программисты своей логикой порой похожи на роботов, они ровно так же подвержены выгоранию от рутинных повторяющихся задач, как и люди любых других профессий. Все время заниматься решением одних и тех же проблем скучно. Монотонность выматывает и это не всегда видно снаружи. Выгорание выражается в том, что разработчик просто не может выполнять свою работу: раньше справлялся за заложенное время, а теперь при тех же задачах производительность труда падает. Описать в такой ситуации свое состояние он сам не может, руководителю приходится самому проявлять проницательность.
У нас во избежание этой проблемы люди бьются на команды, и специалисты могут переходить из одних в другие, меняя направление. Иногда человек явно высказывает желание перейти, а иногда он просто вдруг начинает жаловаться на все подряд. Если обвинить человека в этот момент в лени, он просто уйдет в другое место. Ошибка думать, что человек перетерпит скуку и успокоится, лучше перевести его на другие задачи. На собеседовании мы спрашиваем у людей, куда они хотят двигаться. В данном случае или, если сотруднику скучно, им также можно подбирать обучающие курсы.
5. Вред быстрых расспросов
Нередко менеджер думает, что может поймать программиста и задать все вопросы, при этом, чем быстрее он их все задаст, тем будет проще. Когда программист делает мелкие задачки, это действительно так — он может остановиться, ответить и спокойно продолжить работу. А вот если задача большая и сложная, то когда кто-то приходит, вырывает из контекста, задает вопросы и заставляет думать про что-то другое, это вмешательство обходится дороже. Разработчику в итоге нужно заново тратить время на погружение в свою сложную задачу. Возможность всегда быстро спросить что-то у исполнителя приводит к тому, что ответы он дает, но свою задачу выполнять не может. При приближении дедлайнов это самый верный способ их сорвать.
Чтобы задавать вопросы, нужно подбирать для них время. Лучше всего задавать их на утреннем созвоне. На звонке всей командой обсудить, кто что делает, есть ли какие-то проблемы, кто может помочь и дальше не отвлекать разработчиков. Для уточнения текущего статуса задач всегда есть доска, на которой сотрудники отмечают, над чем работают, а что закончили. Понятно, что вопросы все равно могут возникать, но их лучше задать тимлиду, а не прерывать разработчика от мыслительного процесса. Иначе это будет лишь тормозить процесс, как постоянное открывание крышки при попытке быстро вскипятить воду в кастрюле.
Проблемы и вопросы программистов очень похожи, что 20 лет назад, что сейчас. Единственное, в чём не соглашусь с автором - очень не люблю образ программиста, описанный здесь. Такое обидчивое, волосатое существо.
Приведу цитату:
"В среде общительных людей это не будет проблемой — один спросит, другой подскажет. Однако у программистов все иначе. Здесь тот, кто имеет достаточно знаний и понимает, как решить задачу, может оказаться крайне нелюдимым".
Я не встречал программистов, у которых нелюдимость является признаком профессии. Так и хочется сказать - всё, как у людей. "След-то человечий" - это из студенческого фольклёра, знаете все. )) Обычные люди, кто-то смешлив, кто-то немного тугодум, кто-то усидчив, кто-то любит быстро набросать каркас, а потом долго дорабатывать.
Автор совершенно верно пишет о "переводчиках", о "скрытых возможностях", о "мучительных думах". Да, это так - когда погружаешься в задачу, то очень трудно выползти из неё и дать мгновенный ответ на мгновенный вопрос руководства. Но замечу следующее. Этот фактор погружения далеко не нов и в других профессиях. И человечество давным-давно придумало способы работы в этих случаях. Даже не так - начальство научилось не лезть с вопросами к диспетчеру аэропорта в час пик.
Давайте попробуем спокойно разобраться в ситуации. Ну первое - разработка касается не только программистов, а большого отряда специалистов. От техписателей, аналитиков, тимлидов, тестировщиков и пр и др. (Для особо одарённых - здесь аналитик не ловит какие-то туманные сигналы из космоса в шапочке из фольги, как считает у нас один товарищ, а занимается конкретной работой). Более разнообразной команды я не знаю. Строители? Но у них всё-таки более чёткое деление - те, кто работает руками плюс логистика и проектанты.
Наиболее близок к команде разработки дирижёр большого оркестра. Надо подобрать музыку, надо придумать оркестровку, рассадить людей со своими инструментами, и при этом, учтя их темперамент, исполнить огромную партитуру. А ведь в оркестре тоже бваает и депрессия, и однотонность, и даже бухгалтерия. И две гитары или скрипки могут звучат совершенно по-разному.
Больше всего программистам и другим членам команды мешает руководство. Оно, рук-во, может и понимает, и знает всё, что нужно, но уж не надо сильно преувеличивать какие-то особые знания бизнес-тайн. Просто на рук-во давит внешний мир - заказчики, владельцы, инвесторы и даже бывает прокуратура. Вот и врывается директор в панике к разработчику с "очень срочным вопросом".
Уверен, что мы так и не выработали культуру тим-лидерства (сейчас я очень широко применяю этот термин). Техзадание запутано, требования непонятны, цели - некая шарообразная конструкция, язык постановки задачи напомнинает некоторые наши федеральные законы - в них надо сначала половину слов повычёркивать, чтоб добратся до сути. И всё, все торопятся - ТЗ - срочно, документация - срочно.... До смешного - уже есть ТЗ, есть контракт, уже есть часть кода и интерфейсы, а пояснительная записка к проекту ещё и не начиналась. И это называют привычно "проектной работой"!!! Да у нас 80 процентов документации на разработку служит только одной цели - отчитаться перед заказчиком.
Если не суетиться под клиентом, делать всё обдуманно, а не по аналогии с испуганной кошкой, то весь процесс разработки - это сплошное удовльствие. Это когда есть солидный, уважаемый человек наверху команды, который всю внешнюю суету и немедленные хотелки рук-ва и заказчика тихо и спокойно тушит (мужчина или женщина лет 60-ти). Это склонный к планомерной работе тимлидер (40 лет - просто супер!), это умеющий донести задачу аналитик - молодой и дотошный. Когда программист вдруг (о, чудо!) открывает документацию и читает её, а не надеется на пролетарское чутьё тимлида!
И прошу вас, коллеги, не делайте из программистов необщительное небритое чудовище.
То есть это - бритое чудовище?
Ну это неоднозначно!
Вот у меня был программист. Знал кучу анекдотов, бывает очень своеобразно матерился. В отпусках лазил в горы, спучкался на байдарке, покорял пороги.
Брился ежедневно. Ох дефки его любили - значит не чудовище?
Весёлый и общительный, программы клепал, как пирожки.
Нынче в Минцифре работает.
Вы придумали классное название какой-нибудь новой статьи. Её можно назвать "Из жизни бритых чудовищ".
Тема качества разработки - вечна! Уж сколько копий сломали, сколько бумаги исписали. Сколько родилось и скончалось методик. Плодится огромный отряд программистов, а вот никто, на мой взгляд, так и не предложил действительно помогающую методику.
И проблема, по-моему мнению,заключается в уникальности каждого разрабатываемого проекта. Причём кое-что является общим для всех неудачных или не очкень удачных проектов. В эту же группу нужно включить те проекты, стоимость которых увеличилась к окончанию в разы.
И снова и снова проекты начинаются с прощупывания функционала, а уже потом по его результатам готовится документация. За редчайшим исключением (видел такие). Делается обследование объекта, но результат мало похожь на ожидание.
Наш гениальный В.П.Макеев называл себя "режиссёром внедрения". И в его словах оченьбольшой смысл. Знаю, что разработчики очень пренебрежительно относятся к "бумагам", но с моей np? подробная партиутра внедения - пожалуй самое важно, что нужно в нашем деле. И талатливый режиссёр.
Судя по результатам наиболее содержательных исследований на эту тему, два фактора остаются наиболее важными с точки зрения провала проектов - Scope и Communication.
Ситуация не меняется, по сути, десятилетиями. Есть лекарства, но нет волшебной палочки.
И это правильно. А как иначе? Проблема в том, что бизнес аналитики не используют при этом устоявшиеся архитектурные патерны, а пытаются на коленке создать какую то свою архитектуру исследуемой области. В результате, толи из-за малого опыта, толи из-за небрежности, но описание получается не целостным, часто не соответствует требованиям.
А что дадльше... А дальше нужно натягивать на функционал системные объекты в соответствии (и это очень важно) с требованиями TOGAF. Но не зря же американцы закрыли доступ к лицензированию по этому архитектурному фрейсворку.
Вот такая предварительная проектная работа должна быть. Только она может гарантировать абсолютно пропорциональное распределение системных ресурсов в функциональной среде. А пропорциональность это и есть главный принцип любой архитектуры.