Давайте просто предположим, что вы - командный игрок для целей повествования, хорошо?
Падение от благодати
Вы закончили колледж¹ с некоторым базовым пониманием того, что такое биты и байты, почему связанные списки могут иметь две связи между каждым элементом, а не только одну, и понимаете, что программная инженерия на самом деле не является инженерией, поскольку вы на самом деле не придется запачкать руки².
Теперь, наконец, если предположить, что вы не планируете поселиться в удобной башне из слоновой кости ³, вам придется столкнуться, возможно, с самой сложной задачей, с которой вы когда-либо столкнетесь в своей карьере программиста.
Работа с другими людьми. В команде.
Загрузка
Во время своего служения я часто ссылаюсь на программистов из спальни счастливых и веселых 80-х. Вот и мы, в счастливом одиночестве рубимся и по неизвестной причине создавали целое потомство будущих программистов!
Вот где это началось для многих титанов индустрии, которых вы видите сегодня, таких как я и, скорее всего, вы тоже, если вы понимаете, о чем я говорю, которые занимают уважаемые профессиональные должности по всему миру ».
В те дни совместное программирование вне избранных бородатых кадров первопроходцев Unix или бригады темно-синих костюмов, происходящей от производителей электронных пишущих машинок, было почти неслыханным.
Обучение работе в группе стало для многих из нас не только резким шоком, но и совершенно новым опытом. Оглядываясь назад, когда я был студентом, познакомился с ней среди друзей… было довольно приятно. У нас были общие интересы, технологическая мотивация, и мы справились.
Дни в колледже действительно были лучшими, не так ли?
Проблема возникла, когда для большинства нам приходилось выходить на настоящее рабочее место и занимать то же время и пространство с тем, что я причудливо называю «другими».
Регрессионное тестирование
Первоначально задачи должны были быть разделены между людьми, наиболее подходящими для их выполнения, так сказать. Если бы задача была слишком большой, то ее разделили бы между несколькими людьми, которые разгладили бы складки между собой.
Конструктивная, техническая, коллаборационная.
Со временем некоторые проекты неизбежно разрослись, поскольку мир понял, что эта программная вещь, в конце концов, может быть неплохой идеей. Увы, как и во всех других отраслях, культ управления просачивался подобно студенистому кубу в лабиринте (маленьких) извилистых проходов, и все они были одинаковыми.
Изначально технические упражнения по планированию были эффективно удалены, поскольку другие занялись тем, что стало известно как процесс, и начали разделять задачи на основе вещей, называемых временными рамками, начали составлять диаграммы Ганта и даже некоторые из них начали увлекаться надуманными методологиями разработки программного обеспечения и похоронным звеном всей продуктивности - сертификацией.
В рамках этого увлекательного упражнения разработчики были объединены в команды без учета знаний, опыта или актуальности, и на нас обрушились темные века разработки программного обеспечения.
Вопрос начинки
Подумайте, одна из первоначальных концепций команд заключалась в облегчении общения между членами команды.
Небольшие команды могли легко общаться, но мало что сделали из-за отсутствия знаний, опыта или технических специалистов (особенно если присутствовал дизайнер пользовательского интерфейса), в то время как более крупные команды тратили слишком много времени на общение (отправляя слишком много писем, сообщений , или просто спорили друг с другом) и в результате тоже мало что сделали.
Последний «процесс», регулярно повторно принимаемый руководством, затем будет пытаться разделить команды по ролям, как это делалось ранее с самим менеджментом в прошлом ». Некоторые компании даже пытались практически разработать эффективную стратегию определения оптимального размера команды на основе вкусных съедобных продуктов.
Один хорошо известный во всем мире предполагаемый розничный торговец татуировкой даже имел концепцию, известную как две команды по приготовлению пиццы, в которой считалось, что размер команды не должен увеличиваться сверх того, который можно накормить двумя пиццами ».
Технически плохие роли
Роли на этом этапе, как правило, были плохой идеей, поскольку какой-нибудь неудачливый разработчик в конечном итоге становился «руководителем группы» и номинально становился ответственным за команду своих соотечественников.
На самом деле мы этого не хотели, поскольку существовали (и все еще существуют) определенные товарищеские отношения между техническими специалистами, почти форма коммунизма (который на самом деле работает), когда дело дошло до того, чтобы действительно делать вещи, а не возиться с ролями и обязанности.
Затем менеджмент на этом этапе обнаружил, что переход с парашютом в одном из нетехнических специалистов, чтобы возглавить команду вместо реального разработчика, ничего не даст для эффективности или морального духа⁹.
Как прямой результат этого недавно приобретенного факта, они затем придумали своего рода золотую середину, которая в последний раз нашла такой поразительный успех, как грязное поле между окопами, откуда в Первой мировой войне были хорошо видны противостоящие огневые точки пулеметов.
Да, «технический руководитель группы» родился.
Гибридное потомство разработчика и менеджера, которое было успешно парашютировано, по крайней мере, на время, и отчаянно пыталось пройти эту тонкую грань между несчастной марионеткой управления и кем-то, кто мог открыть IDE и иметь возможность снова успешно выйти из нее. В тот же рабочий день.
Убийство ворон
Итак, что можно было сделать?
Технический руководитель группы был кем угодно, только не этим.
Обычный руководитель группы до сих пор сохраняет этот оттенок насмешек и намек на управление будущим для соответствующего человека. Проклятие, если хотите.
А вот пригласить руководителя проекта возглавить команду разработчиков было бы все равно, что бросить крысу в железный резервуар с хорьками, так сказать. Я знаю, я видел это, и это действительно неприятно, когда хорьки понимают, что крыса совсем не похожа на хорька. Еще хуже, если он открывает PowerPoint и пытается объяснить, как все они могут безопасно покинуть резервуар после того, как они заплатили за необходимую сертификацию, завершили и переварили слайды.
Однако компании решили эту проблему, полагаясь на процесс, то есть на то, что ставит галочки перед ними и выполняет задачи - по крайней мере, на их бумаге.
В реальном мире разработчики склонны к самоорганизации, что-то вроде кристаллизации соли или бормотания ласточек на вечернем солнце. Мы знаем свои способности, мы знаем способности наших товарищей, и мы просто хотим закончить работу и получить от этого хоть какое-то удовольствие. Особенно, если мы используем командную строку.
Удобное справочное руководство по размеру команды
Размер команды 1:
Сосредоточенный разработчик, которого в остальном мире сочли бы опасным для общества, но который потусторонний владеет жизненно важной технологией. Кто-то напишет API, чтобы он мог раскрыть свой код, не подвергая опасности других.
Примерами могут быть, возможно, поставщики языка Wolfram Language, Perl или программирования сырых сокетов на C в процессе демона.
Размер команды: 2
Классический бэкэнд-интерфейс. Обычно происходит в небольшой сжатой области, которая четко определена, которая должна иметь какой-то веб-интерфейс для какого-то умного внутреннего кода.
Часто вы можете встретить здесь человека, занимающегося JavaScript, в надежде узнать что-то у настоящего программиста на команда.
Размер команды: 3
Достаточный размер для работы. Один бэкэнд, один интерфейс и один разработчик IoT, поскольку все проекты в наши дни содержат что-то об IoT в своих спецификациях, даже если руководство даже не понимает заглавные буквы, не говоря уже о значении аббревиатуры.
Можно рассмотреть IoT. Машинное обучение в прошлом - упомяните об этом в лифте, и на проект начнут литься деньги. Просто убедитесь, что это настоящий программист IoT, а не изгнанник из машинного обучения¹⁰, который знает только Python и знает, как импортировать библиотеки для расчета средних значений или преобразования литров в бушели.
Размер команды: 4
Оптимальный размер - пара разработчиков низкого уровня, еще один, который немного знает другие «языки», такие как JavaScript и Python, который может склеивать вещи вместе (когда это не обязательно делать правильно), и еще один, который может либо заполнить, сбежать за кофе и закусками, либо успешно отвлечь интерес руководства к самому проекту.
Размер команды: 5+
Независимо от того, что поставщики программного обеспечения для «совместной работы», такие как Teams или Slack, претендуют на то, чтобы сказать в своей эмоционально истощающей рекламе, технически невозможно сотрудничать с 5 или более людьми. Нет. Просто нет.
Я говорю технически не просто так, потому что вполне возможно высмеять руководство за счет клиента (и, естественно, насмешки разработчика) с любым количеством людей, которые на самом деле не заинтересованы в получении все сделано.
Нет отклонения разумной ставки
В статье, в отличие от многих других, есть смысл, а именно: размер вашей команды должен быть небольшим, в идеале около 3–4 человек.
Конечно, это не холм, на котором я предпочту умереть, но он основан на личном опыте, анекдотических историях, рассказываемых поздними вечерами за колесом рулетки, и разочарованном наблюдении за провалами проектов в замедленной съемке на протяжении многих лет в пресловутой поговорке. угольный забой.
Утомленные инженеры, такие как я, все еще в игре, хотя мы по праву должны пить из туманных стаканов на средиземноморских яхтах, готовы проконсультироваться по вашему проекту прямо сейчас, если мы вам понадобимся!
Сформируйте упорядоченную очередь.
[1]: Колледж дополнительного образования, Политехнический институт, Университет - подойдет любое формальное место обучения.
[2]: Кроме лазания под партами для подключения кабелей Ethernet, то есть.
[ 3]: Я открыт для предложений любой разумной декоративной башни, честно говоря, это даже не обязательно должна быть башня. Я бы снял офис на первом этаже. Позвони мне.
[4]: Если ты в это поверишь, ты поверишь во что угодно.
[5]: Я знаю, что многие старейшины работали в одиночку, но sccs действительно существовали по какой-то причине и заполняли ниша.
[6]: Можете называть их ботаниками. Я называю их сосредоточенными.
[7]: Линейный менеджер, Менеджер проекта, Менеджер по продукту,… Ad infinitum.
[8]: Зная их репутацию бережливости, это должно было позволить им идеальный размер команды - один. Или два, если один не появился.
[9]: Или их ежеквартальный обзор сверху в пищевой цепочке.
[10]: Статистика.
