Pull to refresh

Comments 31

UFO just landed and posted this here
Вся надежда на комменты
У нас команда, делала проект с нуля, поменялась часть разработчиков.
Менеджеры, продуктоунеры, агильщики, бекенд, фронтенд, различные тестироващики и т.д. все на одной волне. Все друг друга понимают и стараются не нарушать чужое пространство.
Естественно, каждый понимает, что бизнес в приоритете, из этого и ставятся цели. Однако и бизнес понимает, что бы получить хороший результат, нужна проф. команда и реальные сроки.

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

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

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

(букинг-дистрибьют проект)
UFO just landed and posted this here
То, что со стороны выглядит саботажем, может оказаться простым отсутствием времени и/или интереса ко второй команде. Грубо, наняли вторую команду, а дедлайны у первой не передвинули, а у второй постоянно вопросы и просьбы, а то и требования, по сути и форме напоминающие обращения заказчика в саппорт какого-то интегратора. Причём без попыток анализа проблем на своей стороне, типичное «не работает», хорошо, если логи сразу дадут, а не просить и объяснять где их брать приходится. Ну не резолвится имя локального домена заказчика, ну проверь ты, прежде чем бежать за посощью, что ты обращаешься к его серверу, а не к своему провайдеру, а то и Гуглу.
Да, такое может быть, но только на первом этапе — начало взаимодействия. Если проблемы возникают на этапе внедрения изменений, то это скорее всего уже саботаж.

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

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

А выделение на коммуникации пары часов в неделю, тогда как вторая команда хочет пару часов в день, хотя бы на этапах постановки и приёмки азадачи?

Нет, ну естественно, что первая команда разработчиков/поддержки будет негативно относится ко второй, ведь если ее пригласили, значит первая не в состоянии справиться с работой сама. И тут есть два варианта. Первый: команда «А» действительно не может. Но это бывает редко. Гораздо обыденнее и чаще в игру вступает второй вариант: просто нет времени на рефакторинг своего кода, ведь это нужно собраться, посидеть-подумать и т.д. и т.п. Ну а текущие задачи никто не отменял. Иногда бравые программисты из команды «А» берутся переписывать свой код в свободные минутки, что похвально и правильно, но никем не оплачивается и мало кем замечается.

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

Но, думаю, что такое редко бывает. Если изначально выбрана негибкая архитектура, то это медленная смерть для динамичного проекта.
Первый: команда «А» действительно не может. Но это бывает редко.

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

Так это тоже зависит от команды, которая говорит: «закладываем часы на рефакторинг, иначе проект умрёт».

Чаще такое бывает (в случае аутсорса разработки какого-то компонента), когда команда А может, но у неё более приоритетные задачи. Например, команда А занимается развитием основного бизнес-процесса, а задача маркентинговая типа переделать сайт компании, который эта команда когда-то сделала.

UFO just landed and posted this here
Наверное такое бывает. Но, если воспользоваться простой логикой, то владельцу проекта намного проще вложить деньги в собственную команду (есть доверие, опыт взаимодействия и т.д.) То есть, приглашение второй команды обычно означает неспособность решить задачу, а это перевешивает риск и проблемы поиска.
UFO just landed and posted this here
Да, мы обычно и работаем с компаниями, для которых разработка ПО это не бизнес. В этом случае либо собственные разработчики в офисе/на удалёнке или тоже аутсорс. То есть часто встречаются две аутсорс команды: новая (приглашённая) и старая (которая поддерживает проект).

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


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

Первая сторона. Их основные интересы: сохранить собственный авторитет, самооценку и остаться в проекте, доказать свою незаменимость.

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


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

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


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

На ваших условиях вторая команда не будет работать. Они хотят понятные проверяемые критерии приёмки, а не так, что «я посмотрю, и если ваш код мне не понравится, вы всё перепишете».
Да нет, почему. Работа над кодом оплачивается по оговоренной ставке, независимо от того, приняли или нет. А услуга оптимизации зависимо. Можно ведь так оптимизировать, что станет действительно быстрее, но тронуть там что-то будет нельзя.
Опять же, изменения оговариваются заранее. Не понравиться может реализация, и тогда правда лучше переписать, обычный прием pull-реквеста.
С чем то похожим недавно имел дело.
Команда несколько лет разрабатывала внутренний продукт и сейчас почти все разбежались, а мы, «новички на проекте», разгребаем. Судя по всему, начиная от кода, подходов и выбранных «фреймворков» до процессов CI — на проекте делалось все, чтобы сделать его как можно сложнее, запутаннее, и сохранить как можно больше уникальных знаний о «костылях», зарытых в кучу «Г» (ИМХО).
Сейчас мне очевидно (разобравшись глубже во всем проекте и процессах), что многие вопросы, проблемы и нюансы можно было обсудить, пока команда была еще с нами. Со многими проблемами можно было разобраться быстро, если бы ушедшая команда была действительно в этом заинтересованна.
Часто понимал что мне просто не договаривают о том, что прямо или косвенно касается выполнения моих непосредственных задач.
Впрочем, возможно, не стоит приписывать злонамеренность там, где можно объяснить все простой глупостью.
P/S/ Сейчас команда состоит из умных и адекватных людей, с которыми приятно работать. А проект живет, и, возможно, еще поцветет))
UFO just landed and posted this here
Да, время покажет)
Опять же, если команда знает, что уходит, зачем ей напрягаться и что то вам делать? Команду мотивировали на это?

Не знаю, мотивировали или нет, но разве брать ответственность за свой проект — это плохо? Уходя на новую работу я предпочитал передать все знания по проекту, все особенности и тонкости. Хотел чтобы целостный образ системы был в голове у того, кто будет ей заниматься дальше. Иначе то, над чем я так долго трудился, вкладывал силы и душу, будет размазано по грязной дороге жизненного цикла программы :) (и грязная она потому, что там размазано немало проектов)
На счет ресурсов — да, иногда бывает нужно правильно расставить приоритеты и от многого отказаться. Но бывает достаточно перед началом проекта очень хорошо подумать, штурмовать задачу, сформировать целостный образ — тогда все получится сделать. В некоторых случаях у меня на штурм уходило до 80% времени, которое по факту требовалось для выхода проекта в пилот. Остальное время писал код..)
Пример не из области программирования

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

Да, и такое бывает. Относись к ним по человечески, к их труду и получишь счастливых людей, осознающих свою роль, которые и без давления «сверху» понимают, что они важны (т.к. видят всю картину происходящего и не строят иллюзий).
Получилось немного лично и субъективно, но никому не навязываю)
Спасибо за ответ!)
UFO just landed and posted this here
С какой-то стороны это будет дополнительное напряжение для уходящей команды (да и для бизнеса), причин (почему проект не был передан в необходимом объеме) может быть много.
Они будут нервничать и / или могут сделать только видимость передачи проекта в полном объеме (получим обещанную премию, а дальше трава не расти..) или сразу опустят лапки (если их уже охватило уныние :)).
Лучшая мотивация — это осознание того, что твою работу не выбросят на помойку, что ты тратил бесценное время не зря. Для этого, опять же, нужно стараться делать все так, чтобы не было стыдно передать его другим людям и помнить что никто не идеален, часто новый взгляд на ситуацию — только на пользу делу. Если радеешь за дело, то с радостью поможешь новой команде.

Это конечно идеальные варианты, но мир такой, каким Мы его делаем.

А по жизни и в душе я инженер-программист))
UFO just landed and posted this here
Да, моя личная. И я считаю что подобная мотивация способна принести куда больший результат, чем давление (и контроль) со стороны бизнеса. Сотрудничество лучше конкуренции, но часто бизнес так не работает (есть бизнес, и есть все остальные («любые люди»)).
Говорят, что не нужно бояться сломать устоявшиеся модели бизнеса, если это пойдет ему на пользу.
Вы можете попытаться найти людей в команду с такой мотивацией

Найти такую команду я бы очень хотел) Мне есть чему их научить)) УОХАХА
планируете становится управленцем

Становится управленцем (как они существуют сейчас) не очень хочу, но придет время, ради высших целей стану — и наведу порядок по своему разумению.
Если кто-то будет работать под моим началом в диссонансе от общих целей, то он будет страдать также, как страдает хороший специалист с нерадивым работодателем. Но я помогу приспособиться, было бы желание у самого человека)
По мне так если живешь как Человек, то не важно какую работу ты делаешь, ведь все это делается на твое благо и на благо всех кто рядом. Это как привносить свою искорку света туда, где уже и помнить забыли что такое свет, везде мерещатся страшные тени, и сложно довериться даже одному проходящему силуэту (тем более группе силуэтов, которые еще называют себя бизнес :))
Нужно просто больше света, больше доверия… тогда будет видно куда все идут и что с этим делать, если вдруг заплутали.
При чем тут компетенции управленца? Да ни причем, не важны они. Это просто опыт. В новых реалиях будет нужен новый опыт…
Такое мое мнение)
UFO just landed and posted this here
Судя по всему, начиная от кода, подходов и выбранных «фреймворков» до процессов CI — на проекте делалось все, чтобы сделать его как можно сложнее, запутаннее, и сохранить как можно больше уникальных знаний о «костылях», зарытых в кучу «Г» (ИМХО).

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


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

А почему вы не инициировали обсуждение? И вы не думаете, что та команда могла просто не считать проблемой то, что вы считаете? максимум считать "откроет код и за 5 минут разберётся"?

Возможно просто разница в квалификациях вашей и их

Да, опыт у всех разный, я это понимаю. Как понимаю что и у меня не сразу получалось хорошо. На то он и опыт…
Может позже они бы и рады были всё переписать по уму, но время на это не давали.
Тут уже больше от бизнеса зависит и от их взаимодействия с командой; если проект важный, то все вместе они были обязаны найти выход и направить свою деятельность на улучшение ситуации.
А почему вы не инициировали обсуждение? И вы не думаете, что та команда могла просто не считать проблемой то, что вы считаете?

Инициация обсуждения с моей стороны выглядела бы как — объясните мне то, не знаю что, так, не знаю как). Полным представление о проекте обладает команда, которая его делала. И именно ей следовало по порядку рассказать что это, как работает, какие цели преследует, чем помогает, что требует постоянного внимания, какие есть известные проблемы, какие мысли на будущее развитие и улучшения. Человека нужно погружать в образ, иначе со стороны команды это выглядит как попытка залездь в их голову и такой подход с самого начала взаимодействия не предвещает ничего доброго)))
«откроет код и за 5 минут разберётся»?
Легко, при условии что виден весь образ проекта. Иначе это похоже на чтение вырванных из контекста мыслей, и как учит нас СМИ, допридумывания этой информации ограничено лишь фантазией))
Если резюмировать: необходимо видеть всю картину проекта и относиться к партнерам по-человечески, делая свою работу.
Спасибо за ответ!)

Судя по лайкам баттхёрт таки существует)

Sign up to leave a comment.

Articles