Где можно встретить БР?
Немного контекста. Мы занимается услугами по ускорению сайтов. Обычно это работы над клиентской частью и немного серверного тюнинга. Иногда приходится внедряться в чужой серверный код для решения проблем производительности. В случае наличия команды разработчиков у клиента мы регулярно встречаемся с батхёртом у них.
Для формирования БР нужно три стороны. Далее опишем их вместе с интересами, которые приводят к ситуации батхёрта.
Первая сторона – это команда разработчиков, которая должна иметь достаточную историю взаимодействия с кодом проекта (например, разработка с нуля или долговременная поддержка). Их основные интересы: сохранить собственный авторитет, самооценку и остаться в проекте, доказать свою незаменимость.
Вторая сторона – это другая команда разработки, приглашённая для решения локальных задач: доработка какого-то компонента, аудита проекта, решения проблем производительности, консультации. Их интересы: успешно провести проект, получить кейс, повысить репутацию, дополнительные продажи услуг.
Третья сторона – владелец или менеджер проекта, который и пригласил вторую команду для решения локальной задачи. Его интересы: улучшить качество проекта, решить проблемы для пользователей, увеличить доходы проекта (при этом не потеряв контроля и сохранив все сильные стороны, включая команду разработки).
Природа бархёрта разработчиков различна. Например, это может быть уверенность в собственных силах и правильности решений. В некоторых случаях это страх, что его заменят на более продвинутых разработчиков, которые смогли исправить проблемы в проекте. Иногда – неспособность обучаться и воспринимать новые подходы и технологии. В любом случае, батхёрт приводит к проблемам для всех задействованных сторон.
В чём проблема?
Сложности возникают при попытке взаимодействия команд разработчиков. Первая команда (старожилы проекта) не заинтересована в успехе работы приглашённой команды (или не хочет в него верить). Результат: саботаж всех действий. Начинается это процесс с затягивания сроков передачи доступов к программному коду проекта и заканчивается на блокировке внедрения изменений. Отказ в доступах легко мотивируется вопросами безопасности, внедрение изменений блокируется на базе оценки изменений кода, которые оказываются «неправильными», «ненужными» и «непрофессиональными».
Далее, руководителю проекта докладывается о полном провале приглашённой команды и необходимости отката всех изменений.
Перед руководителем проекта возникает сложный вопрос доверия: с одной стороны команда, которая погружена в проект, имеет значительный лимит доверия (проект как-никак работает). С другой стороны – приглашённая команда, с которой он работает первый раз, лимит доверия которой заведомо ниже.
Если руководитель обладает достаточной технической подготовкой и сможет разобраться в реальном положении дел – хорошо. Однако, на этом история не закончится. Далее ему придётся продавить свою команду принять изменения и «посыпать голову пеплом». Это может в свою очередь вызвать новые проблемы.
Если руководитель не может самостоятельно разобраться в деталях спора, то скорее всего он выберет путь наименьшего сопротивления – отказаться от проекта с приглашённой командой и принять точку зрения своих разработчиков. Этот вариант наименее конфликтный, но приводит к провалу начальной задачи (доработка проекта, аудит).
Как лечить?
Здесь у меня нет однозначного ответа. Могу предложить только несколько методов.
Метод №1 – коммуникации. С самого начала нужно наладить эффективную связь между командами разработки, объяснить всем сторонам цели и задачи проекта. Здесь важна обратная связь и понимание процесса всеми сторонами. Неизвестность порождает страх и недоверие.
Метод №2 – отключаем эмоции. Все мы люди и нам свойственно реагировать эмоционально. Особенно это актуально, когда речь идёт о своём детище (программном коде). Вся аргументация в спорах должна быть основана на объективных данных и логике (если в вашем проекте есть четкие критерии и метрики – отлично). Ни в коем случае нельзя переходить на личности и терять деловой тон общения.
Ну и последний, который метод профилактики, а не лечения – страхуйте риски. Если заранее знать о проблеме батхёрта, можно предусмотреть этот риск в договоре, предупредить заказчика и т. д.
А вы встречались с батхёртом разработчиков в своей практике (с любой стороны)? Как боролись?
Комментарии (30)
YaRobot
13.12.2017 19:52+1У нас команда, делала проект с нуля, поменялась часть разработчиков.
Менеджеры, продуктоунеры, агильщики, бекенд, фронтенд, различные тестироващики и т.д. все на одной волне. Все друг друга понимают и стараются не нарушать чужое пространство.
Естественно, каждый понимает, что бизнес в приоритете, из этого и ставятся цели. Однако и бизнес понимает, что бы получить хороший результат, нужна проф. команда и реальные сроки.
Как то не было, что бы команды с другими в чем то конфликтовали, да и внутри команд все тихо. Пришел новый человек, предложил идею, ее рассмотрели и приняли (ну или не приняли, такого правда не было.).
За два года разработки проекта, был только один человек, который всем не нравился и его идеи тоже. В итоге компания с ним распрощалась. Данный товарищ, просто лил в уши воду и требовал финансирование. Когда поняли что все это вода, ушел не один миллион.
Как мне кажется, надо просто подбирать профессиональную команду и к ней прилагать человечка, который рассказывал бы, зачем мы все тут собрались.
У нас такой имеется (назвал агильщиком, но это от части), он рассказывает, зачем мы тут и т.д.
Ну и настроение команды поддерживает =)
Каждый занять четко своим делом, каждый понимает тонкости бизнеса.
Опять же, по ключевым вопросам, всегда идет общение с бизнесом.
(букинг-дистрибьют проект)
VMichael
13.12.2017 20:43+2Вы описываете работу внутри одной команды.
Это совсем не тот случай, который описывает автор в статье.
VolCh
13.12.2017 22:37То, что со стороны выглядит саботажем, может оказаться простым отсутствием времени и/или интереса ко второй команде. Грубо, наняли вторую команду, а дедлайны у первой не передвинули, а у второй постоянно вопросы и просьбы, а то и требования, по сути и форме напоминающие обращения заказчика в саппорт какого-то интегратора. Причём без попыток анализа проблем на своей стороне, типичное «не работает», хорошо, если логи сразу дадут, а не просить и объяснять где их брать приходится. Ну не резолвится имя локального домена заказчика, ну проверь ты, прежде чем бежать за посощью, что ты обращаешься к его серверу, а не к своему провайдеру, а то и Гуглу.
Nickmob Автор
14.12.2017 09:07Да, такое может быть, но только на первом этапе — начало взаимодействия. Если проблемы возникают на этапе внедрения изменений, то это скорее всего уже саботаж.
VolCh
14.12.2017 11:20+1На ревью чужого кода тоже нужно время, которое могут отдельно не выделять. И замечания по стилю кода тоже могут считать саботажем. Или отказ принимать пулл-реквест без согласования с ИТ-директором включения в зависимости сторонней библиотеки.
Nickmob Автор
14.12.2017 11:27Как правило, саботаж выражается в полном отказе от коммуникаций, а не предъявлении требований и замечаний. С замечаниями хоть как-то можно работать, а с полным отрицанием — сложнее.
VolCh
14.12.2017 11:47А выделение на коммуникации пары часов в неделю, тогда как вторая команда хочет пару часов в день, хотя бы на этапах постановки и приёмки азадачи?
JuniorNoobie
14.12.2017 09:06+1Нет, ну естественно, что первая команда разработчиков/поддержки будет негативно относится ко второй, ведь если ее пригласили, значит первая не в состоянии справиться с работой сама. И тут есть два варианта. Первый: команда «А» действительно не может. Но это бывает редко. Гораздо обыденнее и чаще в игру вступает второй вариант: просто нет времени на рефакторинг своего кода, ведь это нужно собраться, посидеть-подумать и т.д. и т.п. Ну а текущие задачи никто не отменял. Иногда бравые программисты из команды «А» берутся переписывать свой код в свободные минутки, что похвально и правильно, но никем не оплачивается и мало кем замечается.
Вот если бы в поддержку проекта закладывались часы на рефакторинг кода, на его аудит и ревью! И была бы возможность просто сказать: «Все, архитектура исчерпала себя, мы не предполагали, что наша система должна уметь то-то и то-то, это не закладывалось нами в изначальный проект. Нужно переписать проект с нуля с учетом новых факторов. Иначе мы получим медленное неповоротливое чудовище на костылях».
Но, думаю, что такое редко бывает. Если изначально выбрана негибкая архитектура, то это медленная смерть для динамичного проекта.Nickmob Автор
14.12.2017 09:10Первый: команда «А» действительно не может. Но это бывает редко.
Бывает и не редко, именно о таких случаях и идёт речь в статье.
Вот если бы в поддержку проекта закладывались часы на рефакторинг кода, на его аудит и ревью!
Так это тоже зависит от команды, которая говорит: «закладываем часы на рефакторинг, иначе проект умрёт».
VolCh
14.12.2017 11:25Чаще такое бывает (в случае аутсорса разработки какого-то компонента), когда команда А может, но у неё более приоритетные задачи. Например, команда А занимается развитием основного бизнес-процесса, а задача маркентинговая типа переделать сайт компании, который эта команда когда-то сделала.
VMichael
14.12.2017 10:36+1Ага, пошло немного обсуждения.
Бывает негатив первой команды вызван тем, что для расширения команды не выделяют ресурсов, длительный период. Потом команду обвиняют в том, что она не справляется и вваливают много ресурса (денег) во вторую команду, приглашенную. Первая команда чувствует себя незаслуженно оскорбленной, ибо, если бы хотя бы часть выделенных для 2 команды ресурсов досталась 1-й команде, необходимость во 2 команде не возникла бы.Nickmob Автор
14.12.2017 10:42Наверное такое бывает. Но, если воспользоваться простой логикой, то владельцу проекта намного проще вложить деньги в собственную команду (есть доверие, опыт взаимодействия и т.д.) То есть, приглашение второй команды обычно означает неспособность решить задачу, а это перевешивает риск и проблемы поиска.
VMichael
14.12.2017 10:47«Владельцу проекта».
Можно сделать отступление.
Мне встречалась описанная в статье ситуация, когда «владелец проекта» сменился. Пришел новый руководитель, который отдает предпочтение аутсорсу. Ему с ним понятнее. Переговоры, договор, сроки, деньги. Речь про компанию, для которой разработка ПО не ее бизнес, просто поддержка основного бизнеса.
А вы рассматриваете какие компании и какие ситуации?Nickmob Автор
14.12.2017 11:03Да, мы обычно и работаем с компаниями, для которых разработка ПО это не бизнес. В этом случае либо собственные разработчики в офисе/на удалёнке или тоже аутсорс. То есть часто встречаются две аутсорс команды: новая (приглашённая) и старая (которая поддерживает проект).
VolCh
14.12.2017 11:46Бывает вторую команду приглашают на условно одноразовые задачи из-за отсутствия желания временно расширять штат. Опять же, если решить расширять команду, то нужно заниматься подбором кадров с какими-то рисками ошибиться в выборе, а с подрядчиками есть договорные отношения обычно с "фиксед прайс" и различными неустойками. Ну и общая кадровая политика компании может быть такая, что не должен рядовой инженер получать больше начальников отделов (речь про не ИТ-компании), а в ИТ это сплошь и рядом, то есть бюджет на расширение команды будет заведомо ниже бюджета на подрядчиков со всеми вытекающими.
Это без учёта каких-то узкоспециализированных задач, которые своя команда если и может решить, то долго это будет делать. Обычные задачи, которые с одной стороны имеют важное значение, но с другой меньший приоритет перед текущим пулом задач своей команды. Скажем, в бизнесе задачи одного отдела имеют высший приоритет, а задачи других отделов постоянно откладываются и их представители начинают роптать, сваливать на разработку свои неуспехи в показателях, типа "мы бы выполнили план, но наша задача разработчикам уже 4 месяца без движений"
michael_vostrikov
14.12.2017 14:31Первая сторона. Их основные интересы: сохранить собственный авторитет, самооценку и остаться в проекте, доказать свою незаменимость.
Их основные интересы касательно взаимодействия с вами — чтобы вы не сломали что-то, что потом придется исправлять им, а также не допустить изменений, которые будут сложны в поддержке, и которые придется переделывать или поддерживать тоже им.
Вторая сторона. Их интересы: успешно провести проект, получить кейс, повысить репутацию, дополнительные продажи услуг.
Сделать лишь бы работало здесь и сейчас, подписать договор, а потом хоть трава не расти.
Аудит сторонних специалистов это хорошо и правильно, только он должен быть не в форме "мы сделаем, а вы разбирайтесь потом", а в форме "мы советуем сделать так по таким причинам", с код-ревью постоянной командой, а также с метриками до и после.
qw1
14.12.2017 20:12На ваших условиях вторая команда не будет работать. Они хотят понятные проверяемые критерии приёмки, а не так, что «я посмотрю, и если ваш код мне не понравится, вы всё перепишете».
michael_vostrikov
14.12.2017 20:30+1Да нет, почему. Работа над кодом оплачивается по оговоренной ставке, независимо от того, приняли или нет. А услуга оптимизации зависимо. Можно ведь так оптимизировать, что станет действительно быстрее, но тронуть там что-то будет нельзя.
Опять же, изменения оговариваются заранее. Не понравиться может реализация, и тогда правда лучше переписать, обычный прием pull-реквеста.
NikolayRychkov
14.12.2017 16:26+1С чем то похожим недавно имел дело.
Команда несколько лет разрабатывала внутренний продукт и сейчас почти все разбежались, а мы, «новички на проекте», разгребаем. Судя по всему, начиная от кода, подходов и выбранных «фреймворков» до процессов CI — на проекте делалось все, чтобы сделать его как можно сложнее, запутаннее, и сохранить как можно больше уникальных знаний о «костылях», зарытых в кучу «Г» (ИМХО).
Сейчас мне очевидно (разобравшись глубже во всем проекте и процессах), что многие вопросы, проблемы и нюансы можно было обсудить, пока команда была еще с нами. Со многими проблемами можно было разобраться быстро, если бы ушедшая команда была действительно в этом заинтересованна.
Часто понимал что мне просто не договаривают о том, что прямо или косвенно касается выполнения моих непосредственных задач.
Впрочем, возможно, не стоит приписывать злонамеренность там, где можно объяснить все простой глупостью.
P/S/ Сейчас команда состоит из умных и адекватных людей, с которыми приятно работать. А проект живет, и, возможно, еще поцветет))VMichael
15.12.2017 00:20Ваш случай можно будет рассмотреть через несколько лет. Кто знает, не сменит ли вас третья команда, с такими же словами.
Опять же, если команда знает, что уходит, зачем ей напрягаться и что то вам делать? Команду мотивировали на это?
Опять же, бывает (редко), что зажимают ресурсы (я снова о своем), а когда команда упарилась и народ разбежался, делают правильные выводы и финансирование увеличивают и вновь пришедшие не понимают, как это раньше не были сделаны такие нужные вещи.
Пример не из области программирования. Был у нас гениальный работник склада на складе одного из клиентов (занимался приемкой и оформление грузов). Супер организовал свою работу. Потом при ЗП 20 000 рублей, попросил прибавку в 5 тыс. Ему отказали. И он ушел в компанию другую, тут же на соседний склад (там большой хаб, много клиентов). И оказалось, что он тащил такой объем, для закрытия которого пришлось нанимать 3 (трех) человек, потому как не справлялись, хоть убей. ЗП каждого по 20 000. Было занимательно наблюдать метания руководства этого направления.
Все это очень субъективно. Очень часто для программиста свой код — близок к идеалу в существующих условиях, а вот другие программисты, просто криворукие гамадрилы :)
И еще. Команда умных и адекватных людей может быстро превратиться в свою противоположность, если этих людей перегрузить задачами до выгорания.NikolayRychkov
15.12.2017 11:56Да, время покажет)
Опять же, если команда знает, что уходит, зачем ей напрягаться и что то вам делать? Команду мотивировали на это?
Не знаю, мотивировали или нет, но разве брать ответственность за свой проект — это плохо? Уходя на новую работу я предпочитал передать все знания по проекту, все особенности и тонкости. Хотел чтобы целостный образ системы был в голове у того, кто будет ей заниматься дальше. Иначе то, над чем я так долго трудился, вкладывал силы и душу, будет размазано по грязной дороге жизненного цикла программы :) (и грязная она потому, что там размазано немало проектов)
На счет ресурсов — да, иногда бывает нужно правильно расставить приоритеты и от многого отказаться. Но бывает достаточно перед началом проекта очень хорошо подумать, штурмовать задачу, сформировать целостный образ — тогда все получится сделать. В некоторых случаях у меня на штурм уходило до 80% времени, которое по факту требовалось для выхода проекта в пилот. Остальное время писал код..)
Пример не из области программирования
Да, достаточно часто встречается такое. Думаю в каждом конкретном случае можно было по-человечески договориться и страдать не пришлось бы ни работодателю, ни работнику.
Сам бывал в таких ситуациях, сейчас понимаю что в некоторых случаях мог подвести ожидания работодателя, но им не стоило забывать про бас-фактор, я всегда был готов заниматься с «запасным» человеком, но его не было))
близок к идеалу
К этому можно стремиться
криворукие гамадрилы
Такие, наверно, тоже бывают, но если стараться, то руки выпрямятся, и гамадрил эволюционирует)))
Команда умных и адекватных людей может быстро превратиться в свою противоположность, если этих людей перегрузить задачами до выгорания.
Да, и такое бывает. Относись к ним по человечески, к их труду и получишь счастливых людей, осознающих свою роль, которые и без давления «сверху» понимают, что они важны (т.к. видят всю картину происходящего и не строят иллюзий).
Получилось немного лично и субъективно, но никому не навязываю)
Спасибо за ответ!)VMichael
15.12.2017 12:46+1Не знаю, мотивировали или нет, но разве брать ответственность за свой проект — это плохо? Уходя на новую работу я предпочитал передать все знания по проекту, все особенности и тонкости.
Не знаю, кем вы работаете, позволю себе небольшой совет по этому поводу.
Вопрос организации процесса.
Хорошие процессы должны мало зависеть от конкретного человека, от его морали и желания.
К вашему примеру. Руководитель должен был озаботиться передачей проекта и мотивировать уходящую команду. Например мотивацией (что лучше): Хорошо передав проект, получите премию дополнительную. Или демотивацией (что хуже): Плохо передав проект, вы не получите «обычную» премию. Определив критерии оценки «плохо» и «хорошо». И в этом случае резко возрастает вероятность хорошей передачи проекта.
Это я про объяснение нюансов новой команде. Как пример :)
С остальными вашими тезисами я в целом согласен.NikolayRychkov
15.12.2017 13:51С какой-то стороны это будет дополнительное напряжение для уходящей команды (да и для бизнеса), причин (почему проект не был передан в необходимом объеме) может быть много.
Они будут нервничать и / или могут сделать только видимость передачи проекта в полном объеме (получим обещанную премию, а дальше трава не расти..) или сразу опустят лапки (если их уже охватило уныние :)).
Лучшая мотивация — это осознание того, что твою работу не выбросят на помойку, что ты тратил бесценное время не зря. Для этого, опять же, нужно стараться делать все так, чтобы не было стыдно передать его другим людям и помнить что никто не идеален, часто новый взгляд на ситуацию — только на пользу делу. Если радеешь за дело, то с радостью поможешь новой команде.
Это конечно идеальные варианты, но мир такой, каким Мы его делаем.
А по жизни и в душе я инженер-программист))VMichael
15.12.2017 14:30Лучшая мотивация — это осознание того, что твою работу не выбросят на помойку, что ты тратил бесценное время не зря.
Это ваша личная мотивация. Не делайте обобщения на этой основе.
Вы можете попытаться найти людей в команду с такой мотивацией (как их распознать, это вопрос), но может и не получиться. А бизнес должен жить дальше, с любыми людьми. И вот тут встает вопрос организации процессов.
Впрочем, если вы не планируете становится управленцем (а это отдельные компетенции), то можете выбросить это из головы.NikolayRychkov
15.12.2017 16:01Да, моя личная. И я считаю что подобная мотивация способна принести куда больший результат, чем давление (и контроль) со стороны бизнеса. Сотрудничество лучше конкуренции, но часто бизнес так не работает (есть бизнес, и есть все остальные («любые люди»)).
Говорят, что не нужно бояться сломать устоявшиеся модели бизнеса, если это пойдет ему на пользу.
Вы можете попытаться найти людей в команду с такой мотивацией
Найти такую команду я бы очень хотел) Мне есть чему их научить)) УОХАХА
планируете становится управленцем
Становится управленцем (как они существуют сейчас) не очень хочу, но придет время, ради высших целей стану — и наведу порядок по своему разумению.
Если кто-то будет работать под моим началом в диссонансе от общих целей, то он будет страдать также, как страдает хороший специалист с нерадивым работодателем. Но я помогу приспособиться, было бы желание у самого человека)
По мне так если живешь как Человек, то не важно какую работу ты делаешь, ведь все это делается на твое благо и на благо всех кто рядом. Это как привносить свою искорку света туда, где уже и помнить забыли что такое свет, везде мерещатся страшные тени, и сложно довериться даже одному проходящему силуэту (тем более группе силуэтов, которые еще называют себя бизнес :))
Нужно просто больше света, больше доверия… тогда будет видно куда все идут и что с этим делать, если вдруг заплутали.
При чем тут компетенции управленца? Да ни причем, не важны они. Это просто опыт. В новых реалиях будет нужен новый опыт…
Такое мое мнение)
VolCh
15.12.2017 10:55Судя по всему, начиная от кода, подходов и выбранных «фреймворков» до процессов CI — на проекте делалось все, чтобы сделать его как можно сложнее, запутаннее, и сохранить как можно больше уникальных знаний о «костылях», зарытых в кучу «Г» (ИМХО).
Возможно просто разница в квалификациях вашей и их, причём их на тот момент, когда код писался. Может позже они бы и рады были всё переписать по уму, но время на это не давали.
Сейчас мне очевидно (разобравшись глубже во всем проекте и процессах), что многие вопросы, проблемы и нюансы можно было обсудить, пока команда была еще с нами. Со многими проблемами можно было разобраться быстро, если бы ушедшая команда была действительно в этом заинтересованна.
Часто понимал что мне просто не договаривают о том, что прямо или косвенно касается выполнения моих непосредственных задач.А почему вы не инициировали обсуждение? И вы не думаете, что та команда могла просто не считать проблемой то, что вы считаете? максимум считать "откроет код и за 5 минут разберётся"?
NikolayRychkov
15.12.2017 12:27Возможно просто разница в квалификациях вашей и их
Да, опыт у всех разный, я это понимаю. Как понимаю что и у меня не сразу получалось хорошо. На то он и опыт…
Может позже они бы и рады были всё переписать по уму, но время на это не давали.
Тут уже больше от бизнеса зависит и от их взаимодействия с командой; если проект важный, то все вместе они были обязаны найти выход и направить свою деятельность на улучшение ситуации.
А почему вы не инициировали обсуждение? И вы не думаете, что та команда могла просто не считать проблемой то, что вы считаете?
Инициация обсуждения с моей стороны выглядела бы как — объясните мне то, не знаю что, так, не знаю как). Полным представление о проекте обладает команда, которая его делала. И именно ей следовало по порядку рассказать что это, как работает, какие цели преследует, чем помогает, что требует постоянного внимания, какие есть известные проблемы, какие мысли на будущее развитие и улучшения. Человека нужно погружать в образ, иначе со стороны команды это выглядит как попытка залездь в их голову и такой подход с самого начала взаимодействия не предвещает ничего доброго)))
«откроет код и за 5 минут разберётся»?
Легко, при условии что виден весь образ проекта. Иначе это похоже на чтение вырванных из контекста мыслей, и как учит нас СМИ, допридумывания этой информации ограничено лишь фантазией))
Если резюмировать: необходимо видеть всю картину проекта и относиться к партнерам по-человечески, делая свою работу.
Спасибо за ответ!)
VMichael
Постановка проблемы хорошая.
А вот решения в статье нет, жаль.
Nickmob Автор
Вся надежда на комменты