В детстве я считал библейскую историю про Вавилонскую башню — странноватой сказкой, пока не начал сталкиваться с аномалией непонимания людьми друг друга чуть ли не каждый день в программных проектах. Простыми словами суть истории про башенку такая: люди «кодили» большую, страшшшшную, мощщщную систему и до того усложнили архитектуру и заумничались — что стали запутываться, наступать друг другу на ноги, руки и головы и вся конструкция стала колом к чертовой матери — команда развалилась и переругалась, «фрилансеры» с дубинами в руках, глиняными дощечками (вместо ноутов) под мышкой и запасами копченого мяса разбрелись по земле.
И в 21 веке, в эпоху расцвета науки, математики, логики — история повторяется в точности до истерики. Давайте разберемся, почему же так случилось, была ли применена магия ситхов и постараемся выработать несколько принципов, ведущих нас к успеху — запустить программный проект вовремя, без экспоненциального превышения бюджета, без матерного экзорцизма и с позитивным осадком за не зря потраченное время у членов команды.
Но прежде всего давайте посмотрим на «строителей», кто мы?
Программирование — это, простыми словами, упорядочивание многомерного хаоса желаний человечества в набор команд для тупого, но при этом очень быстрого процессора. Железная логика, пропитанная строгой математикой и огромная скорость и рождают магию — жизнь на дисплее, многомерную реальность, игры и т.п. Занимаясь этим ежедневно, читая массу книг и, главное, просматривая и частично понимая код коллег — разработчики интенсивно тренируют собственный мозг, сидят на нейронах в шпагате отрицательной кривизны и поневоле, сами того не желая… становятся искрящимися снобами, гоняющими «менеджеришек» по офису одним только взглядом.
Но за развитый ум нужно платить дань ситхам.
Постоянно развивая мозг, разработчик каждую неделю становится другим. С одной стороны — человек растет. С другой: случается беда — смотря на собственный код 2-3 недельной давности, а еще лучше 3-6 месячного срока выдержки — возникает непреодолимое желание выругаться нестандартными и запрещенными UTF-последовательностями, желая передать отвращение от… да, да, собственного кода. Ты поменялся парень, стал гораздо круче и опытнее — и тебя всегда, всегда будет воротить от собственной работы из недалекого прошлого. Но этот симптом, к счастью, лечится пониманием процесса — все ОК, ты стал другим, более совершенным, ты — на верном пути!
Но есть еще большая проблема, которую пока никто не научился эффективно лечить — это баги. Никто, как правило, сознательно их не допускает, но, наступая при решении сложных задач на ограничения собственного мозга (обычно не хватает «оперативной памяти» из-за вытесненного контекста при переключении между задачами) — человек… ошибается. Этот симптом пытаются лечить методиками снижения сложности:
— увеличивают связность кода, помещая его в функции и/или методы объектов;
— снижают зависимость компонентов системы друг от друга, нередко используя либо паттерны проектирования, либо «правильные» языки программирования (воплощающие правильные паттерны);
— не используют бездумно все возможности языка (exceptions, множественное наследование, шаблоны).
Но, к сожалению, абсолютного лекарства пока не придумали. Баги: рогатые, глазатые, с множеством ножек и ручек и всех возможных цветов — были, есть и видимо будут с нами на протяжении, как минимум, ближайших столетий.
Тем не менее — можно совершать гораздо меньше ошибок, если хорошо и отчетливо понимать что ты делаешь и зачем. Если ты видишь непротиворечивое описание библиотеки, алгоритмов, идеи, архитектуры, в разных видах и проекциях и аккуратно, трепетно — ты добавляешь к системе собственную работу. И главное — когда в проекте правильно и открыто коммуницируются — ты начинаешь получать от собственных усилий все большее и большее удовольствие!
Разработчики могут отлично коммуницировать между собой на уровне простого и продуманного API и, гораздо менее интенсивно, на уровне исходного кода. К сожалению, хорошее, промышленное, продуманное и последовательное API создается довольно редко. Не зря регулярно появляются книжки с исповедями опытных и грамотных разработчиков библиотек на тему почему все было сделано сначала не очень правильно и не очень умно, и обещанием впредь думать лучше и тестировать подольше. Понятно, что не все работают в Sun/Oracle и большинство API будут, как бы мягко выразиться… не совсем последовательными.
Из-за относительно небольшого шанса коммуницировать на уровне API, нередко приходится влазить в исходники методов и построчно, с валидолом и фонариком пытаться понять логику коллеги. Не секрет, что некоторые люди из-за повышенного уровня мидихлориан обладают особым талантом писать код, на понимание 2-5 строк которого требуются часы, а то и дни медитации.
В обстановке жестких дедлайнов и меняющихся требований — разбираться с таким ребусом вряд ли кто-то будет и рождается «бездумный копипаст». Однажды созданное «мозговое извращение» начинает плодиться и расползаться, внося в систему хаос и повышая непрозрачность.
Поэтому делаем первую пометочку в своем менеджерском списке «Убить Билла»: стараться обеспечить создание и совместное обсуждение и проектирование API компонентов/модулей системы. Что будет внутри API — гораздо труднее контролировать, но добиться интерфейса кода с человеческим лицом — вполне достижимая задача.
Это палка о двух концах. Умение писать полезные комментарии в коде — большое искусство. Актуализировать их — может не хватить времени. А нагенерить кучу эмоциональных и бесполезных комментариев и… не актуализировать их потом — может даже школьник. В итоге от многословных комментариев будет только вред.
Довольно часто, особенно в мире XP, практикуется принцип ясного кода, понятного без комментариев. Максимум что можно тут рекомендовать — все таки оставлять подсказки при реализации сложных алгоритмов и бизнес-логики. Без подсказки мы вгоним коллегу в многочасовой медитативный транс с 90% шансом достижения просветления.
Поэтому помечаем: необходимо создать условия (например написать регламент и согласовать его со всеми), рождающие короткие, необходимые и полезные комментарии в создаваемом коде с требованием актуализировать их при изменении кода.
Нередко разработчик — человек занятый, глубоко погруженный в контекст задачи с распотрошенными объектами на стенах, конструкторами на потолке, деструкторами в спинном мозге и свободно летающими вокруг exceptions. Отвлечешь его — и для погружения в контекст потребуется минут 30, если не больше. Поэтому большинство — крайне не любят, когда их дергают.
Именно поэтому и придумали различные методики социальной адаптации занятых работой«злостных социофобов» «гениев». Например в Scrum — это ежедневные standups, где каждый разработчик рассказывает всем коллегам:
— чем он занимался вчера
— чем занимается сегодня
— чем планирует заниматься завтра
Да, это жестоко, прямолинейно — но видимо лучшего способа заставить очень умных людей коммуницировать еще не придумали.
Вы спросите: а почему бы людям не разрешить общаться просто, подходя и обсуждая задачи? Иногда это и правда работает. Но нередко, из-за разной квалификации, это опасно. Ну представьте, если у опытного fullstack-разработчика спросят, что такое процесс в операционной системе; он отошлет к правильной литературке, над которой сам сидел месяцами, отказывая себе в пиве и девочках, а вопрошающий кивнув… скопипастит бездумно решение со StackOverflow — тут и до рукоприкладства и «темной» в серверной недалеко.
Поэтому делаем пометку: очень умных людей нужно коммуницировать — принудительно. Например через ежедневные standups.
Да, можно написать архиподробное ТЗ на 10000 страниц, все спроектировать в нем, разделить на задачи и делать 10 лет. Но так мало кто работает — дорого, долго и получим то, что уже устарело. Как можно поступить иначе — попросить разработчика оценить задачу. Но, будучи человеком очень умным и нередко опытным, зная, что требования могут завтра магическим образом поменяться в худшую сторону — он возьмет время с запасом в Pi*E раз! И будет прав.
Для «борьбы» с злоупотреблением при оценке задач часто используют 2 старых и проверенных метода:
1) Оценка задачи ведущим разработчиком/начальником отдела/техдиром. Но помним — этих людей нужно прокоммуницировать — а в разумное время это не всегда достижимо… Может получится бестолковая поверхностная коммуникация с «косыми» сроками.
2) Просто поиграть в Planning Poker.
На самом деле, Planning Poker — это очень коварный и мощный инструмент коммуникаций, работающий на одну цель — выбить из людей достаточно правдоподобную оценку задачи и закрепить ее. Вспомним, что если 2 человека дали слишком разные оценки — их заставляют публично приводить аргументы, которые слышат остальные члены команды и процесс продолжается до достижения консенсуса. И в итоге — принятая «командой» оценка и ставится задаче: Pi*E часов уже сложно будет протащить.
Помечаем себе: как можно плотнее «соединить» доверенного эксперта с разработчиком, а лучше — провести сеанс игры в Planning Poker. Иногда разработчик может дать адекватную оценку и выполнить задачу в озвученный срок — но, к сожалению, на практике, точность оценки сильно связана с квалификацией и требуются «тяжелая артиллерия».
В связи с разным опытом и квалификацией разработчиков, может случиться так, что кто-то, в силу банальной человеческой лени захочет сделать так, как ему удобнее — а не так, как нужно системе. Это потом может вылезти в виде бомбы замедленного действия при высокой нагрузке, увеличенном объеме данных и т.п. «А возьму-ка я и впендюрю сюда ORM!» — и новогодние праздники у консоли, с оливье возле монитора — обеспечены!
Может показаться, что достаточно попросить разработчика описать алгоритм языком О-нотации и прикинуть его алгоритмическую стоимость… Но, как все знают, это не так. Мы не всегда знаем, как работают используемые библиотеки, не заглянув в исходники на пару-тройку часов. Мало того, мы не всегда знаем, как БД обработает запрос — по каким индексам он взлетит. А когда алгоритмы накладываются друг на друга с включениями многомерных ребусов давно уволившегося коллеги, обрамленных фразой «сложный и нераспутываемый *нокод»… И реальную производительность алгоритма покажет только нагрузочное тестирование.
Для коммуникации тут в первую очередь удобен принцип, уходящий корнями снова в XP — метафора. Простыми словами, нужно постараться описать предлагаемое решение в виде простой метафоры: «это двунаправленный связный список, реализованный стандартным контейнером — и все это обвешано банальным кодом фильтрации входных значений». Так — уже понятно, что там внутри и почти все увидят риски, например, линейного времени поиска значения в списке и т.п. Без упрощения и поиска простой метафоры, которая публично обсуждается с коллегами — в код может попасть какая-нибудь тяжелая конструкция с квадратичными алгоритмами, которая устроит бессонные ночи и выходные системным администраторам и клиентам.
Метафоры полезно публиковать для всеобщего обозрения и обсуждения — в wiki. Любой может добавить комменарий, лайкнуть или прийти и «дать по физиономии». Да, жестоко — но зато открыто и справедливо.
Делаем пометочку: разработчики публично озвучивают в виде простой метафоры, с использованием «простых и понятных» всем терминов из теории алгоритмов, кодируемое решение. Делается попытка оценить алгоритмическую стоимость — либо планируется нагрузочное тестирование. Не допускать, чтобы под Новый год под шумок, оливье и шампанское кто-нибудь незаметно не прикрутил ORM к коду обработки учетных данных клиентов.
Не все догадываются, но нередко цели у данных ролей в проекте — разные! Если у менеджера с хребтом есть цель — запустить проект примерно в срок, то у разработчика могут быть «немного другие» цели:
— попробовать использовать библиотеку А, не совсем нужную, но интересную
— попробовать покодить на языке Б для строки в резюме
— реализовать алгоритм, понятный только одному человеку, повысив себе карму
Эти эксперименты, скорее всего, повредят проекту через внезапное повышение сложности кода и уровня вхождения, ухудшат коммуникации внутри команды и вызовут удорожание поддержки системы — но, блин, хочется!!! Опытный менеджер должен научиться чувствовать данную «научно-эротическую жилку» в душе программиста и выводить задумки особо умных представителей человечества на чистую воду и публично обсуждать идеи с командой. Ведь иногда бывает наоборот — новаторские идеи могут помочь проекту, перевести его на новый уровень и он станет и проще и дешевле и быстрее. Но понять и оценить риски — в условиях сжатых релизов довольно трудно и поэтому общий метод тут: упрощать алгоритмы, использовать проверенные библиотеки и решения, снижать сложность — к сожалению…
Исторически сложилось так, что разработчики часто воспринимают менеджеров как менее развитых представителей человечества, не освоивших программирование — хотя это, конечно, не так. Умение правильно общаться и эффективно управлять, быть лидером когда нужно и плечом, когда тяжело — это похлеще шаблонов в C++!
Тем не менее, неопытный менеджер может стать легкой игрушкой в руках алгоритмизированного мозга программиста и должен быть всегда на чеку. Минимальный джентльменский набор такой:
— не вступать в персональные споры, принимать решения командой и следовать им
— не навязывать разработчику свои дилетантские познания в определенных областях
— не запрашивать персональных оценок задачи, оценивать задачи совместно либо с привлечением экспертов
— не отвлекать людей от работы понапрасну, создавать творческую позитивную атмосферу, уметь мотивировать и хвалить
Менеджер, зомбируемый программистом:
Условия для коммуникаций в команде
В заключение разберем еще несколько полезных и эффективных способов, позволяющих проще общаться:
1) Меньше перегородок и стен между разными проектными командами и функциональными подразделениями
2) Больше досок с маркерами для спонтанного общения и мозгового штурма
3) Поощрение обсуждений, поиска причин проблем
4) Поощрение всплытия косяков и проблем наружу с их публичным обсуждением и линчеванием
Мы кратко обсудили наиболее важные риски в программных проектах, связанные с общением и мешающих нам достичь цели в срок. Прошлись по психологии и типичным кейсам, мешающих коммуникации и пометили как снизить их влияние. Заглянули и увидели, как эти задачи решаются гибкими методологиями. Поняли, что опытные, прекрасные звездные разработчики-гении без обеспечения правильных каналов коммуникаций и прозрачного проектного фреймворка — поневоле зазомбируют менеджеров, построят очередную вавилонскую башню, вызовут гнев владыки ситхов инаступит, обязательно наступит новый всемирный потоп… появится новый форк! :-) Удачи и успехов нам всем в достижении эффективных коммуникаций внутри команд!
И в 21 веке, в эпоху расцвета науки, математики, логики — история повторяется в точности до истерики. Давайте разберемся, почему же так случилось, была ли применена магия ситхов и постараемся выработать несколько принципов, ведущих нас к успеху — запустить программный проект вовремя, без экспоненциального превышения бюджета, без матерного экзорцизма и с позитивным осадком за не зря потраченное время у членов команды.
Но прежде всего давайте посмотрим на «строителей», кто мы?
Почему программисты такие умные?
Программирование — это, простыми словами, упорядочивание многомерного хаоса желаний человечества в набор команд для тупого, но при этом очень быстрого процессора. Железная логика, пропитанная строгой математикой и огромная скорость и рождают магию — жизнь на дисплее, многомерную реальность, игры и т.п. Занимаясь этим ежедневно, читая массу книг и, главное, просматривая и частично понимая код коллег — разработчики интенсивно тренируют собственный мозг, сидят на нейронах в шпагате отрицательной кривизны и поневоле, сами того не желая… становятся искрящимися снобами, гоняющими «менеджеришек» по офису одним только взглядом.
Но за развитый ум нужно платить дань ситхам.
Расплата за ум
Постоянно развивая мозг, разработчик каждую неделю становится другим. С одной стороны — человек растет. С другой: случается беда — смотря на собственный код 2-3 недельной давности, а еще лучше 3-6 месячного срока выдержки — возникает непреодолимое желание выругаться нестандартными и запрещенными UTF-последовательностями, желая передать отвращение от… да, да, собственного кода. Ты поменялся парень, стал гораздо круче и опытнее — и тебя всегда, всегда будет воротить от собственной работы из недалекого прошлого. Но этот симптом, к счастью, лечится пониманием процесса — все ОК, ты стал другим, более совершенным, ты — на верном пути!
Но есть еще большая проблема, которую пока никто не научился эффективно лечить — это баги. Никто, как правило, сознательно их не допускает, но, наступая при решении сложных задач на ограничения собственного мозга (обычно не хватает «оперативной памяти» из-за вытесненного контекста при переключении между задачами) — человек… ошибается. Этот симптом пытаются лечить методиками снижения сложности:
— увеличивают связность кода, помещая его в функции и/или методы объектов;
— снижают зависимость компонентов системы друг от друга, нередко используя либо паттерны проектирования, либо «правильные» языки программирования (воплощающие правильные паттерны);
— не используют бездумно все возможности языка (exceptions, множественное наследование, шаблоны).
Но, к сожалению, абсолютного лекарства пока не придумали. Баги: рогатые, глазатые, с множеством ножек и ручек и всех возможных цветов — были, есть и видимо будут с нами на протяжении, как минимум, ближайших столетий.
Тем не менее — можно совершать гораздо меньше ошибок, если хорошо и отчетливо понимать что ты делаешь и зачем. Если ты видишь непротиворечивое описание библиотеки, алгоритмов, идеи, архитектуры, в разных видах и проекциях и аккуратно, трепетно — ты добавляешь к системе собственную работу. И главное — когда в проекте правильно и открыто коммуницируются — ты начинаешь получать от собственных усилий все большее и большее удовольствие!
API и коммуникации
Разработчики могут отлично коммуницировать между собой на уровне простого и продуманного API и, гораздо менее интенсивно, на уровне исходного кода. К сожалению, хорошее, промышленное, продуманное и последовательное API создается довольно редко. Не зря регулярно появляются книжки с исповедями опытных и грамотных разработчиков библиотек на тему почему все было сделано сначала не очень правильно и не очень умно, и обещанием впредь думать лучше и тестировать подольше. Понятно, что не все работают в Sun/Oracle и большинство API будут, как бы мягко выразиться… не совсем последовательными.
Из-за относительно небольшого шанса коммуницировать на уровне API, нередко приходится влазить в исходники методов и построчно, с валидолом и фонариком пытаться понять логику коллеги. Не секрет, что некоторые люди из-за повышенного уровня мидихлориан обладают особым талантом писать код, на понимание 2-5 строк которого требуются часы, а то и дни медитации.
В обстановке жестких дедлайнов и меняющихся требований — разбираться с таким ребусом вряд ли кто-то будет и рождается «бездумный копипаст». Однажды созданное «мозговое извращение» начинает плодиться и расползаться, внося в систему хаос и повышая непрозрачность.
Поэтому делаем первую пометочку в своем менеджерском списке «Убить Билла»: стараться обеспечить создание и совместное обсуждение и проектирование API компонентов/модулей системы. Что будет внутри API — гораздо труднее контролировать, но добиться интерфейса кода с человеческим лицом — вполне достижимая задача.
Комментарии в коде
Это палка о двух концах. Умение писать полезные комментарии в коде — большое искусство. Актуализировать их — может не хватить времени. А нагенерить кучу эмоциональных и бесполезных комментариев и… не актуализировать их потом — может даже школьник. В итоге от многословных комментариев будет только вред.
Довольно часто, особенно в мире XP, практикуется принцип ясного кода, понятного без комментариев. Максимум что можно тут рекомендовать — все таки оставлять подсказки при реализации сложных алгоритмов и бизнес-логики. Без подсказки мы вгоним коллегу в многочасовой медитативный транс с 90% шансом достижения просветления.
Поэтому помечаем: необходимо создать условия (например написать регламент и согласовать его со всеми), рождающие короткие, необходимые и полезные комментарии в создаваемом коде с требованием актуализировать их при изменении кода.
Коммуникация между программистами
Нередко разработчик — человек занятый, глубоко погруженный в контекст задачи с распотрошенными объектами на стенах, конструкторами на потолке, деструкторами в спинном мозге и свободно летающими вокруг exceptions. Отвлечешь его — и для погружения в контекст потребуется минут 30, если не больше. Поэтому большинство — крайне не любят, когда их дергают.
Именно поэтому и придумали различные методики социальной адаптации занятых работой
— чем он занимался вчера
— чем занимается сегодня
— чем планирует заниматься завтра
Да, это жестоко, прямолинейно — но видимо лучшего способа заставить очень умных людей коммуницировать еще не придумали.
Вы спросите: а почему бы людям не разрешить общаться просто, подходя и обсуждая задачи? Иногда это и правда работает. Но нередко, из-за разной квалификации, это опасно. Ну представьте, если у опытного fullstack-разработчика спросят, что такое процесс в операционной системе; он отошлет к правильной литературке, над которой сам сидел месяцами, отказывая себе в пиве и девочках, а вопрошающий кивнув… скопипастит бездумно решение со StackOverflow — тут и до рукоприкладства и «темной» в серверной недалеко.
Поэтому делаем пометку: очень умных людей нужно коммуницировать — принудительно. Например через ежедневные standups.
Коммуникации при оценке задач
Да, можно написать архиподробное ТЗ на 10000 страниц, все спроектировать в нем, разделить на задачи и делать 10 лет. Но так мало кто работает — дорого, долго и получим то, что уже устарело. Как можно поступить иначе — попросить разработчика оценить задачу. Но, будучи человеком очень умным и нередко опытным, зная, что требования могут завтра магическим образом поменяться в худшую сторону — он возьмет время с запасом в Pi*E раз! И будет прав.
Для «борьбы» с злоупотреблением при оценке задач часто используют 2 старых и проверенных метода:
1) Оценка задачи ведущим разработчиком/начальником отдела/техдиром. Но помним — этих людей нужно прокоммуницировать — а в разумное время это не всегда достижимо… Может получится бестолковая поверхностная коммуникация с «косыми» сроками.
2) Просто поиграть в Planning Poker.
На самом деле, Planning Poker — это очень коварный и мощный инструмент коммуникаций, работающий на одну цель — выбить из людей достаточно правдоподобную оценку задачи и закрепить ее. Вспомним, что если 2 человека дали слишком разные оценки — их заставляют публично приводить аргументы, которые слышат остальные члены команды и процесс продолжается до достижения консенсуса. И в итоге — принятая «командой» оценка и ставится задаче: Pi*E часов уже сложно будет протащить.
Помечаем себе: как можно плотнее «соединить» доверенного эксперта с разработчиком, а лучше — провести сеанс игры в Planning Poker. Иногда разработчик может дать адекватную оценку и выполнить задачу в озвученный срок — но, к сожалению, на практике, точность оценки сильно связана с квалификацией и требуются «тяжелая артиллерия».
Коммуникации при проектировании
В связи с разным опытом и квалификацией разработчиков, может случиться так, что кто-то, в силу банальной человеческой лени захочет сделать так, как ему удобнее — а не так, как нужно системе. Это потом может вылезти в виде бомбы замедленного действия при высокой нагрузке, увеличенном объеме данных и т.п. «А возьму-ка я и впендюрю сюда ORM!» — и новогодние праздники у консоли, с оливье возле монитора — обеспечены!
Может показаться, что достаточно попросить разработчика описать алгоритм языком О-нотации и прикинуть его алгоритмическую стоимость… Но, как все знают, это не так. Мы не всегда знаем, как работают используемые библиотеки, не заглянув в исходники на пару-тройку часов. Мало того, мы не всегда знаем, как БД обработает запрос — по каким индексам он взлетит. А когда алгоритмы накладываются друг на друга с включениями многомерных ребусов давно уволившегося коллеги, обрамленных фразой «сложный и нераспутываемый *нокод»… И реальную производительность алгоритма покажет только нагрузочное тестирование.
Для коммуникации тут в первую очередь удобен принцип, уходящий корнями снова в XP — метафора. Простыми словами, нужно постараться описать предлагаемое решение в виде простой метафоры: «это двунаправленный связный список, реализованный стандартным контейнером — и все это обвешано банальным кодом фильтрации входных значений». Так — уже понятно, что там внутри и почти все увидят риски, например, линейного времени поиска значения в списке и т.п. Без упрощения и поиска простой метафоры, которая публично обсуждается с коллегами — в код может попасть какая-нибудь тяжелая конструкция с квадратичными алгоритмами, которая устроит бессонные ночи и выходные системным администраторам и клиентам.
Метафоры полезно публиковать для всеобщего обозрения и обсуждения — в wiki. Любой может добавить комменарий, лайкнуть или прийти и «дать по физиономии». Да, жестоко — но зато открыто и справедливо.
Делаем пометочку: разработчики публично озвучивают в виде простой метафоры, с использованием «простых и понятных» всем терминов из теории алгоритмов, кодируемое решение. Делается попытка оценить алгоритмическую стоимость — либо планируется нагрузочное тестирование. Не допускать, чтобы под Новый год под шумок, оливье и шампанское кто-нибудь незаметно не прикрутил ORM к коду обработки учетных данных клиентов.
Коммуникация разработчика с менеджером
Не все догадываются, но нередко цели у данных ролей в проекте — разные! Если у менеджера с хребтом есть цель — запустить проект примерно в срок, то у разработчика могут быть «немного другие» цели:
— попробовать использовать библиотеку А, не совсем нужную, но интересную
— попробовать покодить на языке Б для строки в резюме
— реализовать алгоритм, понятный только одному человеку, повысив себе карму
Эти эксперименты, скорее всего, повредят проекту через внезапное повышение сложности кода и уровня вхождения, ухудшат коммуникации внутри команды и вызовут удорожание поддержки системы — но, блин, хочется!!! Опытный менеджер должен научиться чувствовать данную «научно-эротическую жилку» в душе программиста и выводить задумки особо умных представителей человечества на чистую воду и публично обсуждать идеи с командой. Ведь иногда бывает наоборот — новаторские идеи могут помочь проекту, перевести его на новый уровень и он станет и проще и дешевле и быстрее. Но понять и оценить риски — в условиях сжатых релизов довольно трудно и поэтому общий метод тут: упрощать алгоритмы, использовать проверенные библиотеки и решения, снижать сложность — к сожалению…
Исторически сложилось так, что разработчики часто воспринимают менеджеров как менее развитых представителей человечества, не освоивших программирование — хотя это, конечно, не так. Умение правильно общаться и эффективно управлять, быть лидером когда нужно и плечом, когда тяжело — это похлеще шаблонов в C++!
Тем не менее, неопытный менеджер может стать легкой игрушкой в руках алгоритмизированного мозга программиста и должен быть всегда на чеку. Минимальный джентльменский набор такой:
— не вступать в персональные споры, принимать решения командой и следовать им
— не навязывать разработчику свои дилетантские познания в определенных областях
— не запрашивать персональных оценок задачи, оценивать задачи совместно либо с привлечением экспертов
— не отвлекать людей от работы понапрасну, создавать творческую позитивную атмосферу, уметь мотивировать и хвалить
Менеджер, зомбируемый программистом:
Условия для коммуникаций в команде
В заключение разберем еще несколько полезных и эффективных способов, позволяющих проще общаться:
1) Меньше перегородок и стен между разными проектными командами и функциональными подразделениями
2) Больше досок с маркерами для спонтанного общения и мозгового штурма
3) Поощрение обсуждений, поиска причин проблем
4) Поощрение всплытия косяков и проблем наружу с их публичным обсуждением и линчеванием
Выводы
Мы кратко обсудили наиболее важные риски в программных проектах, связанные с общением и мешающих нам достичь цели в срок. Прошлись по психологии и типичным кейсам, мешающих коммуникации и пометили как снизить их влияние. Заглянули и увидели, как эти задачи решаются гибкими методологиями. Поняли, что опытные, прекрасные звездные разработчики-гении без обеспечения правильных каналов коммуникаций и прозрачного проектного фреймворка — поневоле зазомбируют менеджеров, построят очередную вавилонскую башню, вызовут гнев владыки ситхов и
