Обо мне
Я работаю в сфере разработки программного обеспечения 28 лет. Моя нынешняя должность — старший директор по развитию программного обеспечения консалтинговой компании в Остине, штат Техас. Я работаю на этой должности чуть более шести лет.
Мой рост был изначально технического характера — я начинал как программист-аналитик как только закончил колледж. Одним из моих любимых хобби в те времена было высмеивание глупости менеджмента. Лишь позже я обнаружил у себя способности к менеджменту и осознал, что мне это действительно нравится.
Во Вселенной работает довольно жестокий вид кармы.
В моем нынешнем положении в качестве старшего директора по развитию программного обеспечения у меня есть 6 менеджеров по развитию, которые отчитываются передо мной. Только в моей организации около 50 разработчиков программного обеспечения. У нас завидно низкая текучесть кадров и очень высокий уровень удовлетворенности клиентов.
За эти годы я поделился со своими подчиненными и их непосредственными подчиненными теми же выводами, которыми я собираюсь поделиться с вами сейчас. Эти выводы — это выстраданная мудрость, а не то, что я интуитивно знал или читал. То есть, я узнал это, пройдя через трудный путь.
Коротко рассказываем о гибкой методологии разработки программного обеспечения (Agile), которую мы используем на проектах в EDISON Software Development Centre.
Я делюсь этим с вами, потому что за последние десять-пятнадцать лет я заметил тихий кризис, разворачивающийся в сфере разработки программного обеспечения, который ведет к снижению качества приложений, недовольным сотрудникам и недовольным пользователям.
Почти во всем виноват плохой менеджмент или может его лучше назвать причудливым менеджментом. В прошлом я был виноват так же как все, пока я не обнаружил и не усовершенствовал базовый набор методов, которые по большей части приводят к тому, что все становится на свои места — по крайней мере, по моему опыту. Никаких обещаний. Поехали!
Будьте осторожны с высокими показателями
Безусловно, вы решили, что некоторые разработчики в вашей команде отличные исполнители. Это обычно те разработчики, которые работают быстро. Менеджеры обычно выбирают и предпочитают этих разработчиков для проектов.
На самом деле отличных исполнителей очень мало и они встречаются крайне редко. Скорее всего у вас их нет. Вы можете думать, что есть и будете сильно ошибаться.
Готов поспорить, что ваши отличные исполнители добиваются таких результатов продуктивности путем технического долга в приложении намеренно или ненамеренно. Они экономят время на дизайне и архитектуре вещей разных уровней (от низкой к высокой — объектов и иерархий носителей, изменения схемы базы данных и т. д.), отсутствии адекватного тестирования и разработке кода, который трудно читать, поддерживать и расширять.
Такие высокопроизводительные исполнители на самом деле обладают очень плохой продуктивностью, если учитывать расчет совокупной стоимости владения. Но если это стартап, где время выхода на рынок имеет наивысший приоритет, тогда обратите внимание именно на вышеупомянутых исполнителей, только пристально следите за дизайном и кодом.
Если работа над дизайном и кодом не особо интерактивна, с большим количеством вопросов и рекомендаций, значит, ваши сотрудники не воспринимают их всерьез или слишком стесняются, чтобы сказать вам об этом. Очень часто один или два разработчика заинтересованы этим проектом, но без очевидного интереса и, глядя на остальных членов команды, даже заинтересованные разработчики предпочтут существенно ограничить свои вопросы и рекомендации.
При наличии должного контроля и руководства, в долгосрочной перспективе, так называемые высокопроизводительные исполнители станут лучше и счастливее. Общая производительность вашей команды ускорится и улучшится.
Поощряйте продолжительное улучшение продукта
Как бы вы не старались, технический долг будет накапливаться: фичи добавляются в приложение с отвратительными последствиями, высоко-приоритетные баги быстро патчатся говнокодом, руководство оперирует нереальными сроками, требования меняются — мы все проходили через это.
Стимулируйте разработчиков улучшать приложение, в то время как они работают над своими проектами. Примерами улучшений является создание объектов для повторного использования из скопированного и вставленного кода и разбивание больших объектов, которые трудно поддерживать, на объекты поменьше, с которыми легче работать по отдельности. Улучшите схему базы данных, даже если это довольно трудно сделать в кратчайшие сроки. Удалите старый и ненужный код. Обновите пользовательский интерфейс, чтобы улучшить опыт пользователей — иногда даже просто изменив пару слов можно заметить большую разницу.
Разработчики, которые привыкли постоянно все улучшать и совершенствовать обычно становятся более счастливыми разработчиками, так как постоянное совершенствование дает им автономию и сильное чувство собственной значимости. Не стоит недооценивать важность боевого духа.
Когда склонность к постоянным улучшениям станет частью ДНК вашей команды, результаты вас поразят. Но дайте время на то, чтобы они проявились, это не произойдет в одночасье. Это также значит, что руководству нужно признать, что на это потребуется больше времени, так как разработчики будут работать над своими основными проектами и параллельно совершать постепенные улучшения.
Непрерывное совершенствование это не самостоятельный проект. Если вы сделаете его таковым, то вы, в конечном счете, найдете повод, чтобы полностью отказаться от него, потому что это влияет на сроки. Это должно быть чем-то, что разработчикам поручат делать во время того как они занимаются своими обычными делами. Это не похоже на сложные проценты. Постоянное совершенствование в конечном итоге перерастет в поразительные результаты.
Поощряйте право собственности на код
Неудивительно, что руководство любит уменьшать риск, рассматривая разработчиков как взаимозаменяемые виджеты. Обычно ожидается, что разработчики ознакомлены со всеми пунктами кодекса. Это уменьшает боль, когда какой-то разработчик покидает команду или компанию.
Это ложная экономия. Вашим сотрудникам нравится работать на вас — верно? — значит, оборот должен быть низким. Не учитывать тот факт, что разработчики могут уйти значит рассматривать нестандартный сценарий вероятных событий. Чтобы добиться лучших результатов, нужно рассматривать стандартный сценарий.
Оптимизация по общему сценарию означает, что разработчикам нужно дать основное право собственности на части кодовой базы и не позволять другим разработчикам менять этот код без одобрения владельца. Это приводит к более высокой производительности труда, поскольку любой разработчик, вероятно, будет знаком с кодом, с которым он обычно работает.
Это также поможет вам определить разработчиков, которые заслуживают отдельного внимания. Некоторые разработчики выпускают больше ошибок так же, как некоторые плотники производят некачественные кухонные шкафы. Например, если разработчик обладает основным правом собственности на пользовательский интерфейс, и вы найдете необычайно огромное количество багов, станет сразу понятно на что вам — как менеджеру — стоит обратить особое внимание и возможно принять меры.
Распознавайте лидеров
Вы без труда заметите, что некоторые ваши разработчики активнее других участвуют в обсуждениях, имеют больше членов команды, к которым они могут обратиться за помощью или советом, чем другие и их чаще приглашают на собрания по разработке, даже если они не будут работать в этом проекте.
Эти разработчики ваши истинные лидеры. Его или её коллеги уже проделали тяжелую работу выявления настоящих лидеров за вас. Эти лидеры должны быть признаны таковыми и требуют специального рассмотрения.
Прежде всего, помните, что быть и разработчиком программного обеспечения и лидером сложно и занимает много времени. Разработка программного обеспечения требует концентрации — концентрации, которая легко теряется после одного вопроса или десяти минут у доски. Вернуться на нужный лад после этого бывает проблематично. Ожидайте, что у ваших лидеров будет уходить больше времени на завершение своих проектов — в конце концов, они делают сразу две работы.
Эти лидеры также должны быть публично признаны таковыми. Их нужно поощрять за работу, которую они уже делают. Так им легче помогать другим разработчикам без обид — это теперь часть их официального описания профессии! — и она обеспечивает им признание, а это поднимает боевой дух. Без этого официального признания, оказание помощи часто может казаться им просто нежелательным бременем. Не позволяйте этому случиться.
Большинство компаний имеют большие накладки в качестве компенсации в таких должностях, как старший программист и ведущий разработчик программного обеспечения, так что финансовой мотивации слишком мало, чтобы отрицать эти акции. Не заставляйте ваших (зачастую стеснительных) истинных лидеров просить о повышении — просто сделай это. Глазурь на торте для вас — как их менеджер вы получите взамен верность и преданность.
Следите за ложными системами показателей
Вы считаете количество работ, которые выполнил каждый отдельный работник? Просмотр этих расчетов находиться в свободном доступе для всех разработчиков программного обеспечения? Даже хуже: у высшего руководства есть доступ к этим данным? Прекратите делать это немедленно.
Разработчики программного обеспечения не так уж и глупы, а некоторые из них быстро узнают, как обыграть систему, если контрпродуктивные средства поощрения видны. Так или иначе, вся работа сведется к достижению самого высокого количества выполненной работы.
Если подсчет рабочих единиц это часть ваших ежедневных или еженедельных собраний, некоторые разработчики научатся решать простые вопросы, чтобы раздуть свой счет. У разработчиков программного обеспечения, которые впиваются в более трудные задачи, которые занимают больше времени, будет сознательно или бессознательно падать боевой дух. Это плохо сказывается на команде и продуктивности.
Еще хуже, когда исправления ошибок включаются в эти подсчеты, когда эти ошибки исправлены разработчиками программного обеспечения, которые сами же и сделали их изначально.
Например, рассмотрим проект разработчика#1, который вероятно будет выполнен за 10 дней без ошибок (или с малым количеством ошибок) и проект разработчика#2, который вероятно будет закончен через 5 дней, но в итоге в нем будут обнаружены 4 ошибки и на их исправление каждой уйдет по 2 дня. И все это без учета дополнительных затрат на поддержку и негативного опыт клиента в результате этих ошибок.
В таком случае разработчик#1 сделал только одну работу за 10 дней, а разработчик#2 пять (сам проект + исправление 4 ошибок) за 13 дней. Кто из них более продуктивен? Ваша система показателей, очевидно, лжет вам. Не доверяйте ей и ни в коем случае ее не афишируйте.
Лимит прерываний
Некоторые сотрудники не осознают, какое влияние они оказывают на других членов команды и часто отвлекают их от работы одним быстрым вопросом или хуже. Приучите вашу команду общаться таким образом, чтобы перерывы были сведены к минимуму: электронная почта, чат (если ваша команда не использует чат, то им стоит начать), мгновенные сообщения, телефонные звонки.
Кроме того, одна из принципиальных позиций, которую должны занимать менеджеры, вне зависимости от того понимают они это или нет, это оборона (брать удар на себя). Внешние люди должны сперва говорить с вами, с менеджером, а потом вы решаете, кого из команды можно включать в работу и когда.
Рекомендации касательно ограничения прерываний мягче, чем предыдущие, поскольку есть тонкая грань между несговорчивостью и сокращением количества сотрудников, которые отвлекают других.
Предпочитайте отдельные рабочие места
Все мы видели фотографии офисов открытого типа, где разработчики программного обеспечения не могут протолкнуться и большинство из них сидят в наушниках в жалкой попытке хоть как-то сосредоточиться.
Несмотря на то, что нет ни единого научного доказательства того, что офисы открытого типа это хорошая идея и есть неопровержимые доказательства того, что они ухудшают продуктивность большинства разработчиков программного обеспечения, они почему-то нынче широко распространены и пользуются популярностью. Разработчикам программного обеспечения нужны личные места. Звуковые и визуальные отвлекающие факторы должны быть сведены к минимуму, что означает, как минимум каждый разработчик должен иметь кабину с высокими стенами и небольшим входом — но достаточно большим, чтобы удовлетворять требованиям безопасности, конечно.
Иногда возникает проект, в котором требуется тесное сотрудничество. В большинстве офисов есть конференц-залы, которые могут быть временно перепрофилированы под открытые офисные пространства.
Поощряйте эксперименты
Мы все слышали о знаменитом 20% времени Google, благодаря которому стало возможно существование Gmail, и все это переросло в успешный онлайн бизнес по разработке приложений.
В то время как у большинства компаний нет огромных денежных ресурсов, чтобы действительно реализовать политику 20%, эксперименты, тем не менее, периодически следует поощрять и поддерживать. Разработчики программного обеспечения не лишены хороших идей и имеют особый опыт, а соответственно у них хорошее чутье касательно приложений, которые могут быть улучшены и расширены.
Дав им свободу действий, чтобы они периодически выполняли исследования и развитие, можно получить неожиданно высокие дивиденды, а также значительно поднять настроение команды. Это также хороший способ, чтобы помочь руководителям выявить настоящих лидеров, которые потратили время, чтобы оценить и рассмотреть более эффективные решения для различных требований. Это не значит, что разработчики программного обеспечения, которые предпочитают работать на работе и отдыхать дома, не достойны вкладчиков — но обратите особое внимание на тех разработчиков, которые думают, что они могут знать лучший способ реализовать что-либо или, возможно, думали о том, что может понравиться клиентам.
Позволяйте сотрудникам уходить
Если сотрудник подходит к вам и просит перейти из одной группы в другую, милостиво позвольте им этого сделать. Это не значит, что вы должны позволить им уйти посреди кризисного времени, но как правило, если они хотят уйти из группы, значит что-то не сложилось, и вы должны позволить им перевестись, даже если они не были в группе очень долго — скажем, менее одного года.
Заставляя сотрудников остаться в группе, вы никогда не добьетесь ничего хорошего. Это повлияет на их моральный дух, который влияет на моральный дух всей группы. Также вполне вероятно, что они станут работать менее эффективно и, в конце концов, просто покинут компанию. Любой менеджер, который не позволяет своим сотрудникам уйти, совершенно не понял, как произвести наилучшее соотношение счастья и продуктивности своих сотрудников, и это ошибка новичка, которую слишком часто совершают даже опытные менеджеры.
Никогда не отклоняйте небольшие просьбы
Ваш сотрудник хочет монитор побольше? Купите. Они хотят определенную клавиатуру? Купите. Они хотят работать из дома каждую среду и это их личное требование? Разрешите. Они хотят Мак вместо ПК? Дайте им его.
Даже если у них постоянный поток запросов, который кажется никогда не закончится, никогда не говорите им нет, кроме одного случая: если вы уверены, что эта маленькая просьба появится у всей фирмы и это действительно будет слишком сильно сказываться на бюджете. По сравнению с зарплатой и премиями осуществление их маленьких просьб будет поддерживать их боевой дух и увеличит продуктивность, а стоит при этом копейки. Если у вас нет бюджета на такие запросы, пришло время, чтобы начать искать работу в другой компании, потому что средний и топ-менеджмент стал никудышным. Если вы отказали в небольшой просьбе недавно, вернитесь к сотруднику и скажите ему, что вы передумали.
Отмените годовые и полугодовые отчеты
Ваши сотрудники не должны ждать шесть-двенадцать месяцев, чтобы узнать, что вы считаете, что они в чем-то преуспели и над чем они должны поработать. Общение между менеджерами и сотрудниками должно быть как река, которая никогда не перестает течь. Слишком много компаний все еще застряли в прошлом с их вредными и непродуктивными периодическими отчетами. Некоторые отчеты даже требуют порой экспертных оценок. В результате сотрудники тайно объединяются, чтобы обеспечить друг другу хорошие отзывы — либо сотрудники, которые не любят друг друга, будут валить друг друга. В любом случае результаты будут совершенно бесполезны и причинят лишь вред. Общение между менеджером и сотрудником не должно происходить во время этих искусственных обязательных периодических встреч с глазу на глаз — которые обычно происходят еженедельно или два раза в неделю - и становятся неудобным требованием в тех случаях, когда нечего обсуждать. И руководители, и сотрудники должны чувствовать себя относительно комфортно, когда общение необходимо. Если сотруднику крайне неудобно завести разговор с менеджером или наоборот это показатель очень серьезной проблемы.
Вы не лучше ваших сотрудников
Разработка программного обеспечения это работа. Управление разработкой программного обеспечения это работа. То, что ваши сотрудники отчитываются перед вами, еще не значит, что вы умнее или лучше них. Многим разработчикам программного обеспечения, осмелюсь сказать, большинству разработчиков программного обеспечения нравится быть разработчиками. Не путайте и не позволяйте вашим работникам путать менеджмент с карьерным ростом — это просто другая работа, даже если за нее платят немного больше. Одна из худших вещей, которую вы могли когда-либо услышать, это как сотрудник говорит, что его карьера застопорилась, потому что его не повысили до менеджера. Нет ничего плохого в одной профессии на протяжении всей жизни, она держит ваш мозг в тонусе, а разработка программного обеспечения остается выдающейся карьерой. Разработчики должны хотеть попасть в менеджмент только по одной причине — потому что они хотят этого, а не потому что считают это шагом вперед.
Не делайте скидку разработчикам помладше или разработчикам постарше
Молодые сотрудники действительно имеют больше энергии, что повышает производительность. Пожилые сотрудники действительно имеют больше опыта и мудрости, которая повышает производительность. Стройте команду с разнообразием в возрасте и смотрите, как они расцветают в нечто большее.
Все возраста играют важную роль и лучшие команды разработчиков, с которыми я работал, всегда имели в своем составе людей всех возрастных категорий — от двадцатилетних до тех, кто приближается к пенсионному возрасту. Они отлично дополняют друг друга. Это трудно объяснить, но легко увидеть с точки зрения менеджмента. Другими словами не позволяйте возрасту играть важную роль в процессе найма, и вы и ваши сотрудники довольно скоро преуспеете.
Не заводите глупые дресс-коды
Как менеджер вряд ли вы много чего можете сказать по этому поводу, но все же позволяйте вашим сотрудникам одеваться небрежно. Понятное дело вы не хотите, чтобы они ходили на работу в пижамах или порванных джинсах, но хорошая пара джинс и любая приличная рубашка с воротником вполне подойдут.
Теперь человечество знает, что одежда не улучшает продуктивность или успех компании. И, конечно, единственными мужчинами, которые носят галстуки, должны быть банкиры или юристы. Ладно, я шучу о той последней части — немного. Позвольте вашим сотрудникам одеваться комфортно. Для кого-то это будут джинсы и рубашка, а для кого-то бизнес-стиль. Они взрослые люди и вы должны позволить им решать.
Обобщение
Эта статься очень долгий и запутанный способ помочь вам узнать, как заботиться о своих сотрудниках по разработке программного обеспечения лучшим образом. Если вы будете должным образом заботиться о своих сотрудниках, то они будут заботиться о вас, что приводит к лучшим результатам и более высокой удовлетворенностью карьерой для вас и для них. Это в основном компиляция здравого смысла, но я чувствовал, что он должен быть собран в одном месте для всех менеджеров программного обеспечения низкого уровня. Хотел бы я, чтобы эта статья существовала в мой первый день работы в качестве менеджера. Все это я узнал на работе методом проб и ошибок и я не могу гарантировать, что это работает для любой команды, но я старался изо всех сил и с нетерпением жду обратной связи. Я уверен, что эта статья описывает все, что должен сделать менеджер программного обеспечения на пути к успеху.
Перевод: Диана Шеремьёва
