Восемь правил эффективного производства программного обеспечения

В течение своей карьеры я участвовал в нескольких реальных проектах по программному обеспечению и наблюдал, как все делается на всех уровнях: принятие решений, внедрение практик, построение команды, рекрутинг, распределение навыков и т. д. Очевидно, что разные подходы давали разные результаты. . Будучи человеком, ориентированным на совершенствование, я подмечал и собирал наиболее эффективные практики и лучшие практические приемы, которые помогут мне в работе.

Учиться на основе наблюдения — трудный и долгий путь. Я был бы очень рад получить эти знания раньше из книг. К сожалению, по теме не нашел. Поэтому я решил поделиться своим опытом с другими искателями такого рода знаний. Надеюсь, это сэкономит им несколько лет личных исследований.

В этой статье вы узнаете, как превзойти среднюю производительность в отрасли, производя прочные и надежные программные продукты, которые требуют в 5-10 раз меньше обслуживания. Могу без ложной скромности сказать, что за последние 10-15 лет я (как лично, так и мои команды) превзошел все ожидания, оставив за собой шлейф успехов. Менеджеры не могут быть счастливее.

Однажды моя команда подтянула важный проект в невероятно сжатые сроки, за что мы получили от высшего руководства награду «Высокоэффективная команда». И все это без ночевок и выходных, изнуряющих себя. Просто нормальная работа.

Видите ли, знание эффективного производства программного обеспечения само по себе является силой. На самом деле, это своего рода черная магия, которую мало кто может понять, даже когда она объясняется простыми словами. Вы получите его бесплатно. Читайте дальше, если хотите, чтобы вас воспринимали как волшебника по производству программного обеспечения.

Это кому?

Позвольте мне сделать здесь важную, важную, важную оговорку.

Я адресую это тем, кто нуждается в повышении производительности. Не все в жизни зависит от продуктивности. Не все программные проекты. Бывают случаи, когда вас не судят по вашей работе. Очевидно, что тогда эти практики не помогли бы.

Эти методы будут наиболее полезны для руководителей групп, архитекторов и менеджеров проектов, хотя старшие разработчики программного обеспечения также могут извлечь из них пользу.

Правило №1: Понимание ИТ-менталитета

IT-индустрия представляет собой смесь науки, технологий, искусства и бизнеса. Без понимания этих аспектов на достаточно хорошем уровне ориентироваться там достаточно сложно. Самая большая проблема заключается в том, что сама отрасль довольно сложна; следовательно, лучшие практики также сложны. Чтобы добиться успеха, вам нужно многому научиться и проверить свои знания, много тренируясь.

Невероятная скорость обновления технологий делает его вдвойне сложным. Ничего из того, чему вы научились десять лет назад, больше не нужно. Так что учиться нужно в ускоренном темпе.

Подводя итог всему вышесказанному, можно сказать, что успех в ИТ-сфере основывается не на врожденных способностях или чувствах, а на жестких практических примерах. Никогда не «следуйте за интуицией» и не верьте исключительно на основе чувств, в том числе ваших.

Если да, то идея достойна внимания. В противном случае потребуйте очень хорошего и очень подробного объяснения того, как выбор этого пути делает жизнь вашей команды лучше. Если он пройдет этот тест, запланируйте упрощенный проект проверки концепции, который экспериментально докажет, что он подходит для вашей среды.

Здесь важно понять, что нет правильных и неправильных решений, потому что существует множество способов решения программных проблем. Однако есть хорошее и плохое понимание решения.

Если человек может четко сформулировать идею в деталях или провести связь между принятием этого решения и успехом команды, чтобы убедить других членов команды, то мы можем положиться на видение этого человека и надеяться на высокие шансы на успех.

Правило № 2: не смешивайте методологии производства и разработки программного обеспечения

Производство программного обеспечения основано на разработке программного обеспечения. Однако у этих двоих совершенно разные цели, мышление и практика. Попытка решить проблему из одной из этих областей методами из другой приводит к нелепым результатам. Важно понимать различие и использовать соответствующие методы для каждого из этих миров.

Разработка программного обеспечения — это сочетание искусства и ремесла. Художественный компонент всегда будет присутствовать, независимо от инструментов автоматизации и методологий разработки программного обеспечения. Поэтому решение задач развития требует максимальной концентрации и ограждения от всех других отвлекающих сигналов.

Лучший способ мотивировать опытного разработчика — представить ему задачу в чисто технической форме, исключив все человеческие факторы. Все требования также должны быть выражены техническим языком. Они должны быть легко проверяемыми, чтобы позволить им двигаться к цели на этапе самостоятельного исследования.

Производство программного обеспечения, напротив, больше относится к сфере делового администрирования. Вы знаете, что нужно вашему клиенту, с одной стороны, и вы знаете, какие командные ресурсы у вас есть в вашем распоряжении, с другой. Итак, теперь вы пытаетесь направить усилия вашей команды на достижение цели. Между тем, вы также можете оценить скорость своего продвижения и представить боссу продуманный план. Важными навыками здесь являются понимание желаний вашего клиента, понимание сильных сторон вашей команды и сообщение формальных планов и графиков.

При этом я хотел бы подчеркнуть, что многие роли в разработке программного обеспечения работают в обоих этих мирах — в построении моста между бизнесом и технологиями — например, руководители групп, архитекторы, аналитики и менеджеры проектов. Люди в этих ролях должны уметь легко перемещаться между двумя планами реальности и понимать, когда пора говорить о делах, а когда — об искусстве.

Правило № 3: Используйте постоянное хранилище как расширение человеческой памяти

Человеческая память, хотя и удивительная по своим возможностям, имеет свои пределы. Вы помните вещи с непредсказуемой точностью и продолжительностью, и когда вы забываете, у вас нет возможности вспомнить это по желанию.

Вот почему мы используем постоянное хранилище памяти, чтобы двигаться вперед с предсказуемой скоростью. Речь идет не о формальной документации, такой как руководства пользователя, которые вы создаете задним числом и для использования другими людьми. Речь идет об использовании документов буквально как внешнем расширении вашей памяти во время работы, которое помогает вам пройти через процесс разработки программного обеспечения.

Я рекомендую вам документировать свои мысли и планы всякий раз, когда вы сталкиваетесь с нетривиальными задачами или задачами, в которых участвует более одного человека. Постарайтесь сделать это как можно дешевле. Не создавайте официальные документы с логотипом компании. Хорошим инструментом будет корпоративная вики с пространством вашего проекта. Создайте специальные страницы для задач или проблем (30 секунд). Затем обновляйте его каждый раз, когда у вас появляется идея или вы собираетесь обсудить ее с другими.

На встрече скажите: «Подождите, дайте мне это записать» и потратьте 10-30 секунд, чтобы выразить это в письменной форме. Написание не должно быть обширным, но оно должно быть полным и связным, как будто вы полностью переносите идею на бумагу. Позже вы или кто-либо другой, читающий ваш отрывок, должен понять его так же ясно, как вы понимаете его сейчас. Этот трюк экономит много времени, но позволяет вам документировать на лету.

Эта техника служит двум целям.

Во-первых, он блокирует ваш прогресс на пути к успеху, сильно вдавливая его в камень. Нет больше риска того, что кто-то что-то забудет, повторит одно и то же снова и снова или пересмотрит то, что уже обсуждалось.

Во-вторых, вы очищаете свой разум, избавляясь от беспокоившей вас проблемы. Теперь ваш разум жаждет следующего вызова. Какой прирост производительности!

Это относится к любому размеру проекта или задачи. Для более крупных у вас будут просто большие пространства с иерархией страниц, которая постепенно растет по мере развития вашего проекта. Важной концепцией здесь является подготовка места для документации и структуры, прежде чем вы начнете свою задачу по созданию протокола быстрого дампа памяти!

Для людей, предпочитающих технологические аналогии, я бы сравнил наш разум с процессором с огромной вычислительной мощностью, но с ограниченной оперативной памятью. По сути, вы можете думать об одной вещи за раз. В этой аналогии ваша документация служит постоянным хранилищем, тогда как ваш разум решает сложные проблемы в итеративном подходе. В какой-то момент вы решаете начать следующую итерацию, прочитать предыдущую документацию и загрузить текущее состояние в свою оперативную память, немного поразмыслив и обновив код и документацию своими новыми выводами. Шаг за шагом, пока он не будет завершен.

При всем вышесказанном я не призываю людей обрабатывать много задач одновременно. Наоборот, чем меньше у вас задач, тем лучше. Тем не менее, не многие рабочие ситуации действительно оптимизированы для человека, и может потребоваться многозадачность, и вам придется как-то с этим справляться. Вышеупомянутый трюк помогает справиться с этим лучше.

Правило № 4: Хватит тратить время на формальную оценку времени

Нет двух одинаковых проектов. В следующий раз, когда вы будете делать аналогичный проект, у вас будут другие клиенты, другие цели, другая команда; может даже разные технологии. Даже используя стандартные инструменты и компоненты, вам все равно потребуется настроить их конфигурацию и архитектуру. Когда вы занимаетесь программными проектами, имейте в виду, что они включают от 50% до 100% индивидуальной работы. Они требуют исследований, обсуждений, размышлений, испытаний и других крайне непредсказуемых действий. На практике вы можете столкнуться с огромной разницей в том, что на первый взгляд кажется одним и тем же типом проекта, и тем, что вы делали раньше. Соответственно, новый тип проекта почти невозможно точно оценить.

Если это так непредсказуемо, то как руководители проектов должны представлять график проекта и придерживаться его?

В литературе описан один формальный способ сделать это; а именно, чтобы разделить весь проект на более мелкие этапы, оценить, сколько времени занимает каждый этап, а затем рассчитать общую продолжительность проекта, объединив продолжительность работы отдельных частей. За этим методом, преподаваемым на курсах MBA, стоит множество теорий.

К сожалению, никакая математика не спасет. Этот метод заведомо неточен, настолько, что он совершенно непригоден для использования и непрактичен, не говоря уже о том, насколько он занимает невероятно много времени. Я никогда не видел менеджера проекта, который использовал бы формальные методы расчета без каких-либо корректировок, даже среди методологических фанатиков. Даже когда компания строго навязала использование такого метода! На самом деле лучшие менеджеры используют совершенно другие альтернативные методы, как описано ниже:

Хороший руководитель проекта обращает внимание на тип проекта, среду, задействованные ресурсы, тип организации и все другие рабочие аспекты, влияющие на фактическую продолжительность проекта. Конечно, никому не нужно учиться исключительно на собственных ошибках. Такие наблюдения могут производиться как прямо, так и косвенно; например, через книги или изучая проекты, выполненные другими людьми, или даже просто передавая знания от человека к человеку. Такие статистические знания на высшем уровне улучшают навигацию по личному графику проекта.

Я хотел бы выделить два важных следствия вышеописанного метода.

Во-первых, точность оценки улучшается с опытом. Невозможно, чтобы неопытный человек, вооруженный какой бы то ни было сильной методологией, смог добиться в этом успеха. Во-вторых, даже самая лучшая оценка хороша только в статистическом плане. То есть можно сказать, что определенный проект может занять от четырех до двенадцати месяцев. Если предположить, что это так, то следует понимать, что существует 50%-ная вероятность того, что проект будет работать в течение восьми месяцев в среднем.

Понимание статистического прогноза имеет такой невероятный эффект. Мудрый менеджер просто поставил бы оценку за 12 месяцев для такого проекта, а затем поразил бы всех, завершив его досрочно. Другими словами, никто не ожидает, что команда будет следовать графику проекта с точностью до дня.

Общий совет руководителям проектов и их начальникам состоит в том, чтобы перестать тратить время на формальные методологии оценки времени. Вместо этого поощряйте сбор статистической информации о продолжительности проекта и распространяйте эту информацию по всей компании. Я знаю компании, где такой подход применялся в масштабах всей компании, что привело к удивительной точности прогнозов.

Правило № 5: Поймите цену переключения задач и жонглирования приоритетами

Человеческий разум удивительным образом устроен природой. Несмотря на то, что это невероятно, у него есть свои ограничения. Другими словами, он предназначен для того, чтобы преуспеть в определенных областях и в определенном типе задач.

Ум разработчика, безусловно, является большим преимуществом в разработке программного обеспечения. Хотели бы вы, как менеджер проекта, лучше понять его и поставить в положение, при котором он работает лучше всего?

Скажем проще, избегая излишней теории. Помните, что теория заводит вас лишь до тех пор, пока вам не понадобится учиться на собственном опыте или опыте других.

Человеческий разум обладает сильным потенциалом решения проблем и генерации идей. К сожалению, не всегда возможно использовать этот потенциал, главным образом потому, что для поддержки генерации идей вам необходимо одновременно держать все части проблемы вместе в своей активной памяти. Поэтому решение сложных задач проходит стадию упрощения, когда задача обобщается или переформулируется, чтобы одновременно вырезать ненужные куски и уменьшить количество сохраняемых в памяти элементов. Другими словами, мы можем решить либо одну очень узкую сложную задачу, либо несколько простых задач.

Однако соотношение не является линейным. Увеличение количества дел, которые вы делаете одновременно, резко ухудшает ваши способности решать проблемы. Вот почему человечество всегда использовало и будет использовать разделение ролей в качестве оптимизации жизни. Два человека, работающие по отдельности над двумя задачами, сделают прорыв быстрее, чем если бы они оба работали над обеими задачами одновременно.

Еще одна важная черта человеческого разума — его неспособность мгновенно переключаться между задачами, как это делают компьютеры. Действительно, вы не можете просто перестать думать о чем-то по своему желанию. Вы также не можете сразу начать думать о новой концепции на полной скорости. Такую умственную инерцию прекрасно иллюстрируют операторы управления воздушным движением. Несмотря на то, что они смотрят на радар и видят полную картину, им все равно нужно загрузить ее в свою память, чтобы действовать быстро. Новому оператору требуется десять минут, чтобы посмотреть на экран, прежде чем он сможет заменить старый при смене.

Что еще хуже, так это то, что мы не можем забыть вещи по своему желанию. Все, чему мы научились, остается с нами и просто постепенно исчезает со временем, занимая пространство, которое мы могли бы использовать для новых знаний. И что еще хуже, этот эффект временами усугубляется ощущением «незавершенности дела». Гораздо легче забыть то, что уже сделано и что вам никогда не понадобится в будущем. Тогда как, когда вы откладываете дела, чтобы закончить позже, ваш мозг естественным образом цепляется за информацию, помеченную как «для использования в будущем», не желая, чтобы новые знания заняли ее место.

Хорошо. Теперь, когда мы обрисовали идею переключения задач, давайте посмотрим, как это работает в реальном (так сказать) мысленном эксперименте.

Представьте, что у вас есть десять постоянных разработчиков, работающих над десятью обычными задачами — по одной задаче на человека. Предполагая, что мы можем поместить их в идеальную среду, свободную от отвлекающих факторов, каждая задача может быть решена за определенное время одним разумом. Все это займет столько времени, сколько потребуется для выполнения самой длинной одиночной задачи.

Теперь давайте повторим тот же мысленный эксперимент. На этот раз мы будем постоянно переключать задачи между разработчиками без (важной) причины. Каждый день каждый разработчик получает новую задачу для работы. Еще лучше, давайте переключать его каждый час. Как вы думаете, как скоро они закончатся? Может быть, никогда.

Менеджер проекта в первом сценарии смог эффективно выполнить проект. Вторым удалось его «казнить», это точно… в том смысле, что они способствовали его смерти. Поздравляем. Этот метод уничтожения проекта особенно эффективен, потому что помимо пустой траты времени он еще и снижает моральный дух сотрудников до нуля.

Большинство людей согласятся с приведенным выше примером, если он будет представлен им в такой чисто академической форме. Однако в реальной жизни они вдруг забывают все под малейшим давлением. Большой босс требует отчет о ходе работы, или заказчик спрашивает о дате реализации определенной функции — практически любое внешнее событие может заставить менеджера проекта броситься к команде и выразить свою обеспокоенность, после чего последует шквал переназначений задач и жонглирование приоритетами в попытаться выиграть немного времени здесь и там, что в конечном итоге не приведет ни к чему, кроме как к еще большему сбиванию проекта с пути.

Это реальный сценарий, который, к сожалению, встречается довольно часто.

Хороший менеджер встает и ограждает команду от таких незначительных помех, поглощая эмоциональную волну и превращая ее в продуктивные темы для будущих дискуссий. Это, безусловно, тяжело эмоционально, но это единственный способ поддерживать команду в хорошем рабочем ритме и позволять ей работать.

Правило № 6. Используйте обзоры архитектуры как способ улучшить дизайн системы

ИТ-индустрия оперирует понятиями чрезмерного и недостаточного проектирования. Когда речь заходит об этом в интервью, все говорят, что чрезмерное проектирование — это плохо. На этот вопрос легко ответить, потому что сам вопрос несет в себе отрицательную коннотацию «сверх», что означает «слишком много». Настоящим практическим ноу-хау будет распознавать, когда ваша архитектура становится перепроектированной, и избегать этого на ранних стадиях.

Позвольте мне дать вам несколько проверенных советов по этому поводу.

Во-первых, решение можно считать перепроектированным, если есть другое более простое решение, обеспечивающее всю необходимую функциональность. Это означает, что если вы не знаете более простого решения, то любое простое решение, которое вы можете предложить, будет лучшим в ваших глазах, если только кто-то не докажет, что вы не правы.

Если наш воображаемый архитектор действительно стремится к совершенству решения, обычный обзор архитектуры гарантирует, что оно достаточно оптимально. К сожалению, обзор архитектуры требует, по крайней мере, нескольких других квалифицированных архитекторов. Во многих случаях он может оказаться недоступным или непрактичным. В отсутствие экспертной оценки архитекторы склонны к типичным ошибкам. Давайте рассмотрим их один за другим и обсудим возможные средства для каждого из них.

Одна из самых распространенных ошибок — проектирование без учета бизнес-целей. Кажется очевидным, что любая трудовая деятельность должна быть привязана к удовлетворению конечного потребителя, успеху компании или аналогичной потребности бизнеса. Тем не менее, часто можно увидеть архитектуру, разработанную полностью или частично без такой цели. Аргументация либо отсутствует, либо сводится к использованию как можно большего количества современных наворотов.

Архитектор в этом случае не делает того, за что заплатил потребитель. Скорее, они играют в прикольные игрушки для собственного удовольствия и удовольствия. Это никоим образом не приемлемо в официальной промышленности. И тем не менее, это, кажется, происходит довольно часто в любом случае.

Иногда проблема кроется в личности архитектора и его одержимости определенными технологиями или инструментами. Им просто нравится их использовать, и они не могут связно объяснить, какую бизнес-задачу они пытаются решить. Близок к этому еще один случай, когда люди ничего не умеют, кроме как строить что-то из мелочей. Конечно, любое внешнее событие вызывает у них желание погрузиться в мир дизайна и больше никогда не возвращаться к настоящему клиенту. Несмотря на то, что первоначальным триггером может быть действительный деловой вклад, их продолжительная оторванность от реальности снижает полезность их произведений искусства.

Лекарство от этого очень простое, но требует самодисциплины. Хороший архитектор никогда не должен прикасаться к ручке и бумаге, пока не сможет четко и честно ответить для себя, зачем это нужно. Такая потребность может проявляться в разных формах. Это может быть формальное требование, неявная потребность в улучшении продукта или появление новых технологий, делающих предыдущий дизайн менее эффективным. В любом случае, это не должно быть формальным триггером, если сами архитекторы понимают движущую силу. Затем они могут использовать эту силу как окончательную проверку качества своего дизайна.

Еще одна трудная для обнаружения проблема связана с мышлением блочной архитектуры. Люди с таким менталитетом верят, что на все есть решение, и это решение всегда реализуется как строительный блок. Другими словами, они напрямую переводят функциональность в компоненты, не оценивая архитектуру в целом. Они могут просто присоединить к системе компонент, предоставляющий желаемую функциональность, когда в ней возникнет потребность. В большинстве случаев это удовлетворяет формальным требованиям, но оставляет систему в некогерентном состоянии. Новый блок не был выбран на основе существующей совместимости системы для разработки, поддержки или даже модели лицензирования компании. Таким образом, команда пытается изменить существующую конфигурацию или реализовать эту функциональность с помощью существующей емкости системы. В результате поддержка и обслуживание системы постепенно превращаются в запутанный кошмар, за которым следует снижение производительности.

У этой проблемы нет простого решения, поскольку разработка системы — это искусство, и никогда нельзя предсказать, нужно ли добавлять новый компонент или его можно избежать. Наилучшей практикой, вероятно, было бы хранение накопившихся с течением времени проблем обслуживания и архитектуры с последующим периодическим пересмотром общей архитектуры системы. Этот периодический обзор может также учитывать появившиеся технологии. Таким образом, общая цель обзоров архитектуры должна заключаться не в устранении проблем, а в оценке потенциальной жизнеспособности желаемых улучшений и системы в целом на фоне надвигающейся неизбежности устаревания.

Правило № 7: Цените игроков команды

Большинству профессионалов ИТ-индустрии на собеседовании задавали вопрос, являются ли они хорошими командными игроками и хорошо ли они работают в команде. Тем не менее, вероятно, никто никогда не видел его четкого определения в литературе. Очевидно, что такой человек будет способствовать успеху команды в целом, но мало кто может реально определить отличительные личностные качества, обеспечивающие такой успех.

Я наблюдал за многими людьми, работающими на разных уровнях, и видел, как их личные качества влияют на ход проекта. Я хотел бы представить следующие указания относительно личных качеств, которые наиболее полезны в командной работе.

Общение

Первое и главное качество, конечно же, это умение общаться.

Представьте себе человека с нулевыми коммуникативными способностями. Конечно, отсутствие обратной связи от членов команды делает их совершенно бесполезными. Это настолько очевидно, что никто на самом деле не измеряет этот навык во время интервью, что подразумевает, что навык находится на достаточно хорошем уровне, если человек может хорошо говорить.

Коммуникация — это не бинарный навык «да/нет»; это скорее окно передачи информации. Чем она шире, тем быстрее и четче происходит обмен информацией.

Поскольку диапазон открытости этого окна сильно варьируется в зависимости от населения, мера ширины такого окна является важной характеристикой командного игрока. Имейте в виду, что в этом контексте мы говорим о передаче информации, а не о плавных разговорах, поощрении людей, их мотивации или организации через разговоры и общение.

Стиль общения также не имеет значения. Информация может подаваться устно, текстуально, в картинках или в смешанном виде. Человек может говорить быстро или медленно. Они могут быть дружелюбными, например, смотреть вам в глаза и все время улыбаться, а могут отводить взгляд и говорить монотонным голосом. Стиль может повлиять на ваше личное восприятие вашего коллеги, но до тех пор, пока вы четко понимаете, что они имеют в виду, любого стиля будет достаточно.

Перейдем к практическим кейсам по выявлению и измерению коммуникативных способностей.

Есть два основных аспекта коммуникативных навыков в целом. Во-первых, это готовность делиться информацией. Кто-то хочет поделиться, а кто-то пытается скрыть информацию. Эта склонность более или менее естественна, но ее можно постепенно изменить с помощью самомотивации и тренировок. Можно с уверенностью предположить, что человек, демонстрирующий один вид готовности к обмену информацией, будет демонстрировать ее и в будущем. Вот почему эта черта хороша для предсказания будущего успеха кандидата в команде.

В реальной жизни людей, пытающихся скрыть информацию, легко заметить. Обычно они пытаются выдать заведомо бесполезную информацию вместо того, что действительно нужно. Или они задают предварительные вопросы, чтобы направить поток информации внутрь себя и свести к минимуму ответы на «необходимые знания». Какова бы ни была их тактика, в конце концов вы почувствуете, что не получили от них желаемой информации или что для получения информации потребовалось слишком много дополнительных усилий.

Важно понять намерение, так как некоторые типы открытого человека могут задать вам предварительные вопросы, чтобы лучше понять ваш вопрос, а затем дать ответ наиболее удобным для вас способом. Человек, намеревающийся скрыть информацию, будет задавать дополнительные вопросы только для того, чтобы увести разговор в сторону, и никогда не будет отвечать на ваш первоначальный вопрос.

Еще одна часть коммуникативного навыка — это способность настраиваться на слушателя.

У разных людей разный уровень понимания темы, разный стиль общения и, может быть, даже разный интерес к конкретным деталям. Некоторые коммуникабельные умные люди будут изменять ход разговора в зависимости от способности слушателя понять его и подготовить свой ответ для предоставления конкретной информации. При такой подготовке могут быть заданы некоторые предварительные вопросы, чтобы сузить интерес слушателя. Умение «отрабатывать» коммуникативные различия — это действительно большое умение, так как оно позволяет добиться взаимопонимания почти во всех случаях. Гибкие собеседники, с другой стороны, могут иногда просто застревать в неразрешимых тупиках непонимания.

Понимание сильных и слабых сторон

Давайте сосредоточимся на другом личном качестве, необходимом для командного игрока.

Большинство людей согласится с тем, что командная среда должна быть более дружелюбной, чем средний окружающий мир, чтобы способствовать сотрудничеству и повышать производительность. Поэтому для команды важно понимать сильные и слабые стороны каждого члена, чтобы правильно распределять задачи и покрывать слабые стороны сильными сторонами. Первым шагом на этом пути является честное сравнение всех участников друг с другом своих навыков. Психологически это может быть тяжело, так как мы естественным образом склонны скрывать свои слабые места от других, защищая себя.

Здесь на помощь приходит дружеская атмосфера в коллективе.

Таким образом, ожидается, что новый участник будет играть по правилам команды. К сожалению, некоторые люди не могут ослабить бдительность даже в дружеской обстановке. Они ведут себя как одинокие волки на протяжении всей своей жизни. Это сильнее их. К сожалению, такое отношение не способствует командным усилиям.

Есть простой способ распознать таких волков-одиночек на собеседовании. Они никогда не признают, что чего-то не знают. Конечно, людям нравится показывать себя с лучшей стороны, демонстрируя все свои способности и пытаясь решить каждую сложную проблему. Тем не менее, есть предел знаний для всех. Наши ограничения формируют наши навыки. Не признавать ограничений означает, что кандидаты представляют себя мастерами на все руки, одинаково хороши во всем и ни в чем.

Когда вы нанимаете специалиста, вы, вероятно, захотите избежать таких людей. Кроме того, такое высокомерное отношение часто сопровождается еще одной тревожной чертой: нежеланием просить о помощи. Умение просить о помощи абсолютно необходимо для совместной работы. Без этого мы не можем прогрессировать и развиваться так быстро. Такой упрямый человек будет сжигать ресурсы и время компании, бесконечно борясь со сложными задачами, но никогда не призывая товарищей по команде на помощь. Есть простой способ обнаружить таких кандидатов на собеседовании. Задайте им вопрос, который не имеет смысла, или упомяните какой-нибудь бессмысленный термин. Нормальный, в идеале любопытный человек просто сказал бы, что не знает, и спросил бы, что это такое. Защищающийся человек никогда бы этого не сделал, даже если вы подчеркнете, что нет правильного или неправильного ответа и что «я не знаю» не дисквалифицирует его.

Правило № 8: Сосредоточьтесь на организации командной работы

Информации об организации командной работы так же мало, как и по любой предыдущей теме выше. Всем известно, что работать в команде лучше, но как создать и поддерживать команду, остается загадкой. Однако, даже если невозможно охватить все аспекты тимбилдинга, мы можем, по крайней мере, изучить здесь несколько ключевых методов тимбилдинга.

Строительная экспертиза

Каждый ИТ-проект уникален. Чтобы добиться в нем успеха, нужно изучить и освоить специфику проекта. Они могут включать как технические, так и нетехнические знания. Примером нетехнических знаний может быть личная сеть для руководства, клиентов, групп технической поддержки и т. д. Специальные технические знания — это дополнительные детали помимо общих навыков в области ИТ.

Например, вам может понадобиться знать Maven для создания проекта. Однако точная структура сборки, расположение свойств и фильтрация по-прежнему будут различаться в зависимости от проекта. Как и в случае с любым типом знаний, овладение такими деталями требует времени; чем больше времени человек вкладывает в это, тем лучше они могут работать. Время — самый ценный ресурс, который у вас есть. Вы хотите, чтобы член вашей команды сосредоточился на одной и той же функциональной области как можно дольше, чтобы извлечь выгоду из их опыта и еще больше развить их, тем самым постоянно повышая производительность команды.

К сожалению, бесконечно это делать невозможно. С одной стороны, людям может быть просто скучно. С другой стороны, вы рискуете потерять их экспертизу, неожиданно поставив под угрозу свой проект.

Давайте посмотрим, есть ли способы справиться с недостатками, не сильно снижая производительность команды.

Распределите области фокуса между членами команды и позвольте им накапливать в них свой опыт. В какой-то момент они достигают достаточно высокого уровня, что имеет смысл в рамках данного проекта. Дополнительные усилия по обучению не принесут значительного улучшения на данном этапе. Без мотивации и вызова умным людям становится скучно, и они начинают ненавидеть свою работу.

Предотвратите это, открыв для них возможности обучения в другом месте. Информируйте их о проектах и ​​технологическом стеке компании, а также ставьте перед ними новые задачи. Если их интерес не выходит за рамки проекта, вы получаете двойную награду, поддерживая вызовы для своей команды и одновременно расширяя набор полезных командных навыков. However, any self development is good to avoid boredom, even if it doesn't intersect with immediate project needs. As long as the team expert brains are engaged, they keep supporting already-learned project areas in the back of their minds.

When leaving the company, team experts take a big portion of expertise with them. One of the countermeasures you can use is to widely disseminate documentation that can be updated on the fly. Think of the “persistent memory storage” mentioned earlier.

Still, a project manager would love to duplicate knowledge in team member heads if possible. Having two of every expert would be a simple solution for that, albeit twice as expensive. But there is a leaner way to do it. The trick is to let most of your developers develop expertise in multiple areas, so that each project aspect is covered by at least one deep expert. At the same time, chose a few senior members to grow the breadth along with the depth of their expertise. Usually, this role is best played by a team development lead or an architect. The team lead interacts with all team members and participates in all task implementations. They can tap into each and every aspect of the project, understanding all of its internals. This way, even if you lose one of the experts, the leader can take over and keep on the project progressing until you can hire and train the replacement.

Another flavor of same idea is to cross-train developers in adjacent areas, letting them to observe, learn, and occasionally try their peers' work. Keep in mind that this cross-training needn't be extensive, so it doesn't disrupt focus on developers' primary tasks and doesn't impede productivity. Developing expertise across leadership and cross-training developers builds you a cushion of protection against unforeseen life culprits and allow you some time to maneuver with project resources.

Minimizing Distraction

Software development is a chain of complex and creative problem solving. Even though, with industry development, these complex problems get more and more automated, the work doesn't become easier. It still involves a large amount of art and individual insight, which is very hard to predict and sometimes even harder to wrangle.

Developers are the edge of the weapon. Their concentration is equivalent to the hardness of the weapon's tip. Increase their focus and you'll cut through problems like a hot knife through butter. Distract them and you'll end up clumsily poking at the butter with a blunted stick.

This cannot be over emphasized: Non-problem-solving work can be intensified with motivation or extra effort. For problem solving work, you need maximum detachment from the mundane world. It is difficult to leave all everyday problems behind, and a good project manager should build a quiet development environment in both the physical and mental senses. A developer's workplace should be analogous to a sensory deprivation tank.

Physically, this is implemented as a closed work space. Every team member should have a cube at least where they can dive into solitude. It is preferable to avoid loud noises and aisle conversations. Quick interpersonal communications should be maintained by emails and chats. Large groups should use closed rooms for their meetings to not distract others. This is a pretty standard picture for office life as it used to be.

Unfortunately, the open space paradigm is being adopted more and more widely even in large offices. I would warn against his fad. Even worse, together with open spaces, top management encourages in-place team conversations. That is, in essence, shouting to a person in another row over an uninvolved team member's head. A developer that is interrupted by loud conversation twenty times a day won't have a shred of concentration left. Certainly a major performance killer.

Allowing for a Learning Curve

Knowledge itself is power. This is especially true for such a complex industry as IT. Every task here has its regular cycle: learn, research, implement. The learning phase in particular is invaluable. Not only does better understanding allow better and faster implementation, there are certain knowledge thresholds that must be passed in order to achieve something at all. Of course, there is no point in over-learning either. Each skill should match the production need and not much above it.

However, often, developers are pressured in the opposite direction; to stop learning and to do nothing but produce. Learning is perceived as wasted effort, as it doesn't move the task progress bar. This seems like a really easy problem to solve, sitting at home and reading this article. Yet in the real life, the slightest work pressure turns every manager into that demanding idiot who insists that everybody “stop learning and start doing something already.” I swear, I have heard those exact words so many times throughout my career… A good manager and team leader should understand that learning is an important part of the process even if it doesn't directly increment the progress bar.

Building a Competitive Development Workshop

The tips and tricks presented above are a subset of effective software production expertise. By understanding and applying them in real life, you'll improve your production effectiveness little by little. If you think they are largely unconnected and lacking a theoretical base, you are absolutely right.

I would like to highlight that building a competitive development workshop is not a single-discipline task. It requires knowledge and expertise in multiple adjacent areas. Building such expertise is a hard work. There is no single theoretical base or idea that would solve all your problems at once. Believing in such a silver bullet just serves to distract you from the real goal.

Try out these tips at work to see if they are worth adopting permanently. If you find them useful (or not), leave a comment below and share your experience!