На днях мне пришло предложение попробовать себя от одной компании, имеющей центр разработки в Киеве. В глаза мне бросился состав команды, который я считаю очень рискованным и неэффективным: 1 backend разработчик, 1 frontend разработчик, 1 QA и 1 PM. В фейсбуке разгорелась дискуссия и нашлись люди, которые считают такой состав вполне себе жизнеспособным. Поэтому я решил описать чуть подробнее в чем суть проблемы и какие риски несет такая команда.
Первая проблема заключается в так называемом bus factor (количество людей, которых должен сбить автобус, чтобы у вашего проекта были большие проблемы). Значение 1 считается очень рискованным, потому что в случае ухода специалиста (в отпуск, другую компанию, на больничный и т.д.) команда не может больше реализовывать функциональность пока не будет найдена адекватная замена. Чем сложнее и больше объем задач на этом специалисте, тем больше усугубляется указанный риск, потому что заменить его становится еще тяжелее. В рассматриваемой команде этот фактор равен 1 во всех направлениях.
Тема данной статьи достаточно противоречивая и спорная. Это скорее идея, которая меня беспокоит последние пару лет, основанная на моем опыте работы и консалтинга в различных компаниях. У меня нет полного решения или продуманного на 100% плана трансформации к новой схеме, но мне кажется, что идея все равно заслуживает внимания. В большей части все сказанное ниже касается аутсорсинговых компаний, хотя достаточно справедливо и для больших продуктовых компаний, которые работают над линейкой продуктов.
Итак, в большинстве компаний минимальной боевой единицей считается один сотрудник (которого все называют как только могут: ресурс, FTE и прочие лейбы). А это автоматически накладывает множество интересных шаблонов. Например, когда в компанию заходит новый проект, то пытаются собрать группу разрозненных сотрудников, отвечающих определенных требованиям, в команду. Или, в случае “схлопывания” проекта, раскидывают сотрудников из команды по другим командам на другие проекты. Ну и наконец, если кто-то в команде захотел развития или поработать с другими технологиями, то его пытаются перевести в другой проект.
Казалось бы, что тут плохого? Совершенно логичная оптимизация. Беда в том, что это локальная оптимизация, которая заточена на улучшение утилизации одного конкретного сотрудника (чтобы все были на 100% “утилизированы”), а не компании в целом. Что, как известно, чаще приносит больше проблем чем прибыли.
(далее…)
Для многих не секрет, что часть компаний приходят в Украину и в целом Восточную Европу с целью сэкономить средства на команде разработки. Зарплаты у нас все еще значительно ниже Европы и США, а рынок хоть и перегрет, но можно найти разработчиков в умеренные сроки. Но смотрите какой забавный сценарий разыгрывается довольно часто.
Понятное дело, что брать одних матерых разработчиков невыгодно – долго искать, экономия не так заметна, да и живет в сердцах старая легенда о том, что только большущая команда может делать большой серьезный проект. Поэтому берется лид, к нему один-два сеньора и добивается состав мидлами или в самом худшем случае начинающими разработчиками. Дрим-тим готов к работе, а заказчики радостно потирают руки – команда разработки набрана за полцены и экономия налицо.
Первое, к чему многие не готовы – это необходимость платить за сам факт удаленности команды. Надо чаще устраивать командировки, больше времени уделять коммуникации, усиливать прослойку менеджеров, вводить более сложные и формальные процессы и инструменты. Многие в изначальной погоне за экономией этот фактор не принимают во внимание. И потом предстают перед фактом, что либо все очень плохо и медленно, либо надо тратить дополнительно кучу денег и тогда бюджет на аутсорсинг не выглядит таким уж привлекательным.
Но это мелочи. Вот что по-настоящему важно. Компания сэкономила, наняла удаленных подрядчиков. Это уже победа и надо ей радоваться, но при этом остановиться в гонке за последующей экономией. Я заметил, что для многих компаний это как наркотик. Получив изначальную команду по выгодной цене они пытаются играть в предпринимателей и ресурсы, постоянно думая о наиболее эффективной схеме их использования и сокращении расходов. Вместо того, чтобы часть из сэкономленного бюджета вложить в команду, ее образование и развитие, они пытаются еще больше сэкономить.
Очень забавно наблюдать как в проекте начинает использоваться новая технология, с которой никто толком не знаком из команды, а для части команды это вообще темный лес. И вместо того, чтобы отправить членов команды на тренинг, заказать консультацию внешнего или внутреннего эксперта, организовать другой способ обучения, все отдается на откуп команде со словами: “пусть разбираются, мы им за это деньги платим”. В результате, куча времени уходит на самостоятельное обучение, команда наступает на все возможные грабли, часто на выходе получается совершенно неоптимальное решение. Но зато ведь сэкономили! Не растранжирили бюджет!
А в результате страдает качество продукта, отношения между командой и заказчиками, уровень доверия. Экономия хороша, но в разумных пределах. И на всем, к сожалению, экономить не получится. Такая экономия напоминает владельцев дорогих машин, которые переоборудуют их на газ в целях экономии, при этом теряя в показателях, увеличивая износ двигателя и сильно уменьшая уровень безопасности. Но ведь экономят же! На себе, но ничего…
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Новые проекты постоянно стартуют, новые продукты начинают разрабатывать, а значит постоянно нужны новые хорошие команды, которые смогут привести проект к успеху. И тут появляется очень интересный вопрос: “кого нанимать в команду первым?”. Казалось бы, что тут сложного в этом вопросе? Оказывается, что ситуация на проекте может очень сильно измениться от одного или иного решения.
Давайте предположим, что первым вы решили взять в команду очень крутого специалиста, так сказать “звезду”. У вас как раз был такой на примете, вы его заинтересовали и пригласили в проект. Естественно, он будет принимать участие в отборе остальных членов команды. Но кого он будет пытаться отобрать? Вероятнее всего, таких же “звезд” как и он или немножко слабее. Для проекта это может превратиться в бесконечную волокиту в попытках расширить команду. Причины такого поведения просты – сильным разработчикам интереснее работать с другими сильными разработчиками. Зато, если вам повезет, вы получите небольшую, но очень сильную и замотивированную команду. Ведь каждый будет понимать, что это отличный шанс поработать действительно со “звездами”. Если же не повезет, то вы не сможете набрать быстро людей, проект загнется или же вы не выдержите и переключитесь на второй вариант.
Во втором варианте вы берете первым в команду хорошего середняка. И тут вступает в силу второй интересный принцип – середняк не будет нанимать людей сильнее себя. Это будут либо люди слабее его, на фоне которых он будет чувствовать себя “звездой”, либо такие же как он. В результате, вы можете достаточно быстро укомплектовать среднюю команду, но вам будет очень тяжело затащить туда сильного разработчика. Демотиватором для него будет уровень других членов команды. Да и для команды одного уровня приход такого сильного разработчика будет демотиватором. Но не факт, что средняя команда сможет сделать именно ваш продукт или проект на высоком уровне качества. А дальше может сложиться так, что середняки уйдут и уровень команды по тому же принципу упадет еще больше. И наступит болото…
Вот такой сложный выбор стоит перед тем, кто собирается набирать команду. Поэтому будьте внимательны и найдите для себя верную комбинацию.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Я вот на днях подумал, что трудно придумать лучший тимбилдинг, чем поехать командой на конференцию в другой город. Приведу несколько доводов, которые мне по опыту кажутся очень вескими:
Во-первых, поездка на конференцию ценна как источник новых знаний и пинок под зад в сторону самообразования. Причем, командой можно все обсуждать и обдумывать в применении к компании и проекту сразу на месте, а не пересказывать потом по приезду. Можно разделиться по разным докладам и собрать еще больше полезных знаний и интересных мыслей. Все это можно будет хорошенько пережевать по дороге домой.
Во-вторых, сама совместная поездка в другой город является своего рода командной работой. Заказать билеты, отель, продумать план поездки, что посмотреть, посетить. Это же очень интересно. В детстве мы мечтали поехать в лагерь хорошей компанией, без родителей и отлично провести время. Еще лучше снять большую квартиру на всю команду и пожить вместе пару дней. Ничего не может быть лучше для понимания друг друга.
В-третьих, вы отрываетесь от повседневных дел и суеты. Вместо этого у вас появляется возможность пообщаться на интересные темы с коллегами. Едете вы на поезде или летите самолетом, времени на общение у вас будет предостаточно. А это и возможность лучше узнать друг друга, обсудить вещи в проекте, на которые никогда не хватает времени, получить много новой информации.
Ну и наконец, чтобы не томить вас длинной статьей, последний довод: путешествовать и знакомиться с новыми людьми – это интересно. А делать это хорошей командой еще интереснее. Ведь у вас будет не только возможность посетить конференцию, но и погулять по достопримечательностям, попить пива в новом месте, развиртуализироваться с людьми, которых вы вроде и знаете, но никогда не видели.
Каждый раз когда я еду на конференцию с кем-то, я привожу гораздо больше с нее. Новые идеи, планы, знакомства, материалы… Поэтому, организуя JEEConf, Selenium Camp, XP Days Ukraine в Киеве, я немного вам завидую. 🙂
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Интересная дискуссия разгорелась в комментариях к моей недавней статье про автоматизацию тестирования. Мне кажется, она вышла за рамки той статьи и было бы неплохо продолжить ее с чистого листа. Тем более, это может быть интересно более широкому кругу для обсуждения.
Итак, началось все вот с такого комментария. Вот самая интересная часть, из-за которой разгорелась дискуссия:
Правда вот я что понял: Николай всегда всё про интернеты и интернеты, но кроме «интернет-софта» есть ещё много другого разного и не везде ваши подходы (да и ваще эджайл) применим. А от повальной увлечённости Скрамом и Канбаном просто тошнит уже.
Впрочем я тоже считаю, что чистый Quality Control не нужен, Quality Assurance – то есть когда происходит реальное тестирование до написания первой строчки кода и убирается любая двусмысленность в том что и как нужно реализовывать и в каком порядке – это идеальный вариант. А потом тестирование чисто юнит-тестами и «автоматизацией» + небольшой QC перед релизом и всё ок.
Вообще у программистов должно быть минимум свободы и минимум вариантов для выбора как реализовывать. Свобода – это рабство, жаль, что всякие ратующие за «полёт творчества» в ИТ этого не понимают.
И тут мы оставили тестирование и пустились в разбор процессов. 🙂 Вот мой ответ:
Много другого-разного конечно существует, но давайте посмотрим реалиям в лицо. Какая разница с какого типа проектами использовать Scrum или Kanban? Это процессы, которые позволяют организовать работу над любого рода проектом (даже не IT). У вас есть свой процесс, который лучше и помогает вам делать быстро и качественно проекты? Расскажите о нем, напишите.
По поводу свободы и вариантов реализации вы заблуждаетесь. Но вероятнее всего из-за того, что вы не программист или просто ваши проекты были достаточно банальными с точки зрения технологий и решаемых задач. Часто надо перебрать много вариантов, чтобы только выбрать потенциально возможный. И тут тестирование – это не банальщина, потому что надо оценить насколько решение справляется с поставленной задачей.
Вот такой последовал ответ:
«По поводу свободы и вариантов реализации вы заблуждаетесь. » – да ладно, хотите поспорить с Оруэллом? Вы ж не забывайте, что «незнание – сила» в дополнение к «свобода – это рабство». То есть правильный подход – это когда те, кто разрабатывают – делают всё в жёстких рамках, а те, кто пользуются – максимально ограничены в возможности выбора и всё закрыто защитой от дурака и нет никакой информации о возможности что-то как-то менять. Шикарный пример – продукция компании Эппл.
«И тут тестирование – это не банальщина, потому что надо оценить насколько решение справляется с поставленной задачей.» – если обрезать все двусмысленности, нечёткие трактовки и детализировать принципы работы системы, жёстко формализовать дизайн по всем аспектам, то реально если не 90, то минимум 80% тестирования, которое требует внешнего контроля (мануальное или полуавтоматическое, всё таки человеческий фактор убрать хрен получится, автотест не скажет «не удобно») можно перевести в процессы до написания первой строчки кода, причём первая имплементация потребует больше тестирования, но чем дальше в лес – тем меньше будет требоваться прямого тестирования, при этом при планировании нового функционала или обновлений будет намного проще убрать лишние риски и уточнить реально важные детали.
Становится интереснее и я принял вызов:
Тут есть одно весьма строгое допущение – «жёстко формализовать дизайн по всем аспектам». Если вы про дизайн и архитектуру кода, то сделать это практически невозможно. В современных проектах они никогда не зафиксированы и всегда находятся в состоянии развития. Вы по-моему пытаетесь применить немного старомодное мышление: зафиксируем требования, зафиксируем дизайн, статически это протестируем, а уже потом за код сядем. Не работает! Доказано практикой многих лет многими проектами…
Но получил вот такой ответ, который задел за живое (именно поэтому решил перенести в отдельную статью эту дискуссию):
Как раз строго наоборот, практика многих лет разработок чего бы то ни было говорит обратное: чем жёстче стандартизация и чем выше требования соблюдать изначальный дизайн от А до Я – тем выше качество результата. То есть если к разработке ПО применить методики разработки, к примеру, марсоходов или ядерных бомб – качество ПО возрастёт.
«В современных проектах они никогда не зафиксированы и всегда находятся в состоянии развития.» – и это адовая проблема, отсутствие жёсткого контроля за происходящим порождает беспредел. То есть не просто «контроля» – контроль как бы есть, но есть отличное мнение, что если раз дать откусить палец, то в следующий раз отгрызут руку, поэтому контроль быть жёстким, а отношение таким: налажал – отгребаешь. Я не ошибусь, если скажу, что сча весь код всего десктопного и мобильного софта состоит из говна и заплаток. Из всего софта, что я пользовал за последний год единственным решением, которое не содержало явных и очевидных глюков – это Вин8, причём чисто сама ось+вин эксплорер, без учёта метро-софта и родного десктопного софта – там ещё тот адок. И то – официально уже вроде 20 апдейтов или даже больше встало, но это всё таки ОСь – многкомпонентная система. А так то релизы один глюкавее другого, все соревнуются не в качестве, а в скорости выпуска, в результате софт превратился в бесконечный поток ширпотребного поноса, который вылетает, глючит и обновляется каждый день, потому что «нафига тестировщики нужны?» или потому что «мы всё сделаем по ХР и со Скрамом». Мир сходит с ума, одни слушают Адель, Бибера и Леди Гагу, другие релизят каждый день новую версию продукта, потому что отладить, отдебажить и месяц-два потестить – нет времени. А о нормальном планировании я вообще молчу. Эхх, нет сча эффективного менеджмента, Ден Кеннеди абсолютно прав.
Почему это меня так зацепило? Да потому что нельзя сравнивать обычные коммерческие проекты с разработкой марсоходов и ядерных реакторов. У них целый ряд ключевых отличий, которые делают их столь же похожими как похожи снегирь и верблюд:
Теперь по поводу частых релизов. Вы думаете это просто? Нет, это гораздо тяжелее попыток выкатить все раз в полгода и потом неделю праздновать, если удалось или по выходным чинить баги в продукте, который может уже и не нужен в таком виде никому. Бизнес развивается гораздо интенсивнее в наши дни и все хотят зарабатывать на продукте деньги. Поэтому делать релизы редко становится убыточным.
Вдобавок, уменьшается стоимость дефектов. Многие проекты четко контролируют работоспособность основного критического для бизнеса функционала. Если нашелся дефект где-то еще, то это не беда. Оно никак не повлияет на бизнес и дешевле быстро починить и накатить обновление. Поэтому, частые релизы – это не от глупости менеджеров или их неграмотности. IT очень быстро меняется и требования к разработке растут с каждым днем. Кто-то может их удовлетворить, а кто-то может пенять на отсутствие “эффективного менеджмента”…
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Опыт вождения по дорогам Киева натолкнул меня на пару интересных мыслей. Все мы знаем, что на дорогах “куча идиотов”. Ровно так же дело обстоит и в разработке – куда ни глянь, страшно на код взглянуть. Почему так происходит? Ведь каждый из нас считает себя классным водителем! Мы умеем быстро ездить, втискиваться между машинами, проскакивать где нельзя и т.д. В общем, быстро добираться до нужного нам места. Да и классным разработчиком многие себя тоже считают. Только дай нам задачу посложнее – наваяем для нее решение очень быстро, возможно даже шаблонов проектирования нагородим. Так в чем же тогда дело?
Все дело в том, что быть классным водителем – это не умение быстро добираться до места назначения. Это, в первую очередь, избегание аварийных ситуаций во время своего движения. Потому что аварийные ситуации повышают риски потерять много времени и денег, как своих так и чужих. Движение с такими рисками никому не нужно (многие просто о них не задумываются). Крутой водитель? Хочешь ездить быстро и перестраиваться из ряда в ряд? Показывай при этом повороты, не подрезай на скорости другого водителя. Не хватает времени или реакции на это? Тогда ты ни хрена не крутой и едь спокойно как все! Действительно классный водитель не гонит, а знает много вариантов проезда, когда надо заранее перестроиться, какую скорость развивать для попадания в “зеленую зону”, грамотно оценивает риски попасть в пробку и принимает адекватные решения…
Ровно те же правила распространяются на разработчиков. Круто “педалишь” код, который вроде работает, но его потом невозможно ни понять ни поддерживать? Ты ни хрена не крутой разработчик! Писать код, который понимают машины могут почти все. Писать код, который понимают другие люди и не тратят много времени на его поддержку и развитие – вот это признак профессионализма. Быстро получить рабочий код низкого качества означает отложить риски на потом, на самый непредвиденный момент. Классный разработчик это понимает. И классный разработчик может писать полностью покрытый тестами, хорошо структурированный, понятный и рабочий код быстрее других. В этом и есть его “классность”! 🙂
Для водителей предусмотрены хоть какие-то штрафы (не будем начинать разговор об их действии в Украине) за ложный “профессионализм”. В разработке их нет и это делает наши проекты из радостных и “цветущих” “дурно пахнущими” и унылыми. А “профессионалы” дуют щеки и рассказывают как они быстро смогут написать любой сложности код…
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
На днях я прочитал вот эту статью и понял, что я действительно благодарен дефектам. Да, никто их не любит. Да, все считают, что без них все равно дело не обойдется. Да, время на исправление дефекта практически невозможно оценить и тяжело контролировать. И при всем этом, я действительно считаю, что дефекты принесли мне много добра.
Начнем с того, что каждый дефект – это своего рода загадка. Иногда в виде “какой дибил мог так написать”, но чаще всего гораздо сложнее, особенно если проект разрабатывается неплохой командой. Эти загадки весьма интересно разгадывать. Могу поспорить, что при виде некоторых дефектов у вас возникала мысль: “этого просто не может быть!”. Решение подобного рода загадок стимулирует мозг и тренирует его на поиск нестандартных и интересных решений.
Дефекты обычно “подлые” и прячутся в самых укромных уголках. Чем больше вы их находите и исправляете, тем больше вы знаете о системе, ее работе и особенностях. Ведь зачастую вам приходится по пути перелопатить кучу кода. Это очень позитивно влияет на ваши будущие задачи, потому что знания системы позволяют вам решать их эффективнее.
Дефекты помогают лучше узнать инструменты и библиотеки, которые используются на вашем проекте. Ведь в них тоже бывают дефекты, по вине которых у вас что-то перестает работать. Если бы не дефекты, очень маловероятно, что я уделил бы столько внимания внутренней работе популярных библиотек. Дефекты стимулируют умение разбираться в чужом коде, читать его и понимать, а это один из главных навыком хорошего разработчика.
Наконец, мы учимся на своих или чужих ошибках. Разобравшись в причине дефекта, вы получаете урок и в будущем уже не наступите на те же грабли. Чем больше таких уроков вы получите, тем более качественным будет ваш код и тем меньше дефектов вы будете делать в будущем.
И, в качестве бонуса, вам всегда есть о чем рассказать. Ведь многие дефекты существуют в единственном экземпляре и именно вы их “выудили”. Это примерно так же как у рыбаков. 🙂
Но не все дефекты обладают перечисленными плюсами. Есть банальные, однотипные и глупые дефекты. Их никто не любит исправлять, они скучны и неинтересны. Но и это большой плюс. Грамотного разработчика подобные дефекты толкают к изменениям в командных процессах и подходах к написанию кода, которые позволят избежать лишней скучной работы. Именно из-за этого меняется работа с тестировщиками, пишется больше автоматизированных тестов разработчиками, применяется TDD, code review и статический анализ кода. Мы стремимся не допускать глупых ошибок.
Именно поэтому я благодарен за каждый найденный дефект. Мне не надо его подробное описание, дополнительные артефакты и прочие популярные вещи. Я готов сам порыться в коде и найти причину – ведь это для меня шанс поучиться, который при этом принесет радость заказчику. 🙂 Задумайтесь, как легко можно кого-то обрадовать и это отлично! Желаю и вам только интересных и поучительных дефектов!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Я заметил, что больше всего сложностей с внедрением Agile подходов вызывает работа над приемочными тестами. Кто-то вообще над ними не работает, кто-то делает это “для галочки”. Но, на мой взгляд, это одна из самых важных и полезных Agile практик, особенно в итеративных подходах.
Все начинается с митинга по планированию итерации. Задача, которая стоит перед командой и Product Owner – не просто обсудить план работ на следующие две недели, но и зафиксировать как можно больше деталей, чтобы избежать проблем в конце итерации. На каждую итерацию команда и Product Owner подписывают внегласный контракт о выполнении определенного объема работ, который определяется совместно. Но в любом договоре стоит оговаривать правила приема-сдачи готовой работы. Без четко сформулированных приемочных критериев все договоренности остаются размытыми и обе стороны могут этим воспользоваться.
Приемочные критерии становятся самой важной целью планирования. Их четкая формулировка позволяет обеим сторонам избежать проблем и недопониманий. Процесс обсуждения приемочных критериев порождает массу вопросов, которые могли не появиться в противном случае. Приемочные критерии станут в дальнейшем почвой для разработки автоматизированных приемочных, функциональных, интеграционных и модульных тестов. Любой написанный тест должен так или иначе иметь отношение к приемочному критерию.
Не менее важный аспект приемочных критериев – хранение информации о функциональности. Когда ваш продукт развивается интенсивно, в него быстро добавляется все новый и новый функционал. Но через некоторое время удержать все это в голове становится очень и очень непросто. Приемочные тесты, которые порождены правильными приемочными критериями, способны не просто сохранить эту информацию, но и привязать ее напрямую к приложению. То есть, в любой момент времени мы имеем возможность не просто освежить в памяти работу определенной части приложения, но и посмотреть ее в действии.
Ну и наконец, приемочные тесты становятся своего рода охранниками реализованной функциональности, живой постоянно активной спецификации к ней. Это своего рода регрессионная защита, цель которой постоянно контролировать сформулированные однажды приемочные критерии и не допускать их поломки в будущем.
Тема очень интересная и я показал лишь несколько моментов, связанных с работой над приемочными критериями и тестами. Для более детального изучения я рекомендую книгу Gojko Adzic “Specification by Example”. Книга действительно очень классная и в прошлом году стала самой популярной книгой на Agile тематику. К сожалению, у Gojko не получилось вырваться на нашу конференцию XP Days Ukraine в этом году. Но мы пригласили его партнера David Evans, тренера и разработчика с 25-летним стажем в IT, приехать и провести тренинг “Specification by Example” перед конференцией. Тренинг подготовлен по материалам книги и будет полезен всем, кто работает в Agile команде, начиная от бизнес аналитиков и заканчивая разработчиками. Данный тренинг в Европе проводится по цене около 1500 евро, но мы сумели договориться на специальную цену для Украины – 3200 гривен. Тренинг пройдет 14-15 ноября и еще есть 5 вакантных мест. Торопитесь зарегистрироваться!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Существует мнение, что большие проекты должны делать большие команды. На первый взгляд все логично. Но, если задуматься немного и посмотреть на работу больших команд со стороны, то можно заметить насколько они неэффективны. Причин много и несколько из них я рассмотрю в этой статье.
Первая причина – затрудненные коммуникации. Чем больше людей, тем тяжелее организовать продуктивное общение между ними. Митинг, который раньше занимал минуты в маленькой команде, в большой может занимать часы. При этом, большая часть участников будет скучать или терять время зря. Такая же ситуация в принятии и обсуждении решений, переписке и планированию командных активностей. Тяжело в большой команде построить демократию, потому что мнений может быть слишком много и консенсуса добиться сложно.
Вторая причина – дополнительные затраты на “обслуживающий персонал”. Всем известно, что в большой команде обычно есть несколько уровней менеджеров. Такой команде тяжело перейти на самоорганизацию из-за размера, поэтому организацией занимаются менеджеры. Позиция менеджера достаточно неплохо оплачивается, а это сильно влияет на бюджет проекта. Также появляются риски разнородных подходов в разных частях команды.
Следующая причина личностная. Тяжело большому количеству разных людей ужиться “под одним зонтиком”. Все мы разные и велика вероятность того, что в большой команде найдутся люди, с которыми нам будет тяжело работать. Следить за возникающими конфликтами приходится менеджерам, а они не все умеют это делать грамотно, что также отражается на продуктивности.
Наконец, в большой команде очень легко “спрятаться”. Можно не работать на всю мощь, а показывать средние результаты. Находятся индивидуумы, которые ухитряются и вовсе бездельничать, “разделяя” достижения со своими коллегами. Уследить за такими товарищами не так просто.
Последняя из рассматриваемых причин техническая. Многие инструменты, которые успешно могут быть использованы в небольшой команде, в большой перестают работать или же требуют платных лицензий. Техническая организация процесса становится гораздо сложнее. В большой команде совершенно по-другому нужно настраивать ревью кода, работу в парах, continuous integration…
Так почему же тогда работают большие команды? Дело в том, что они выгодны модели аутсорсинга. Чем больше людей будет задействовано в проекте, тем больше денег получит компания-аутсорсер. Еще это очень выгодно менеджерам, потому что многие небольшие команды научились работать без них. А им очень не хочется терять свое место с приятной зарплатой и возможностью поруководить. И, пока им это выгодно, они будут прилагать максимум усилий, убеждая клиентов в необходимости строить большие команды для больших проектов. А клиенты будут выкидывать кучу денег на раздутые бюджеты, получая неповоротливую низкоэффективную машину по созданию их продукта…
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
