С какой-то стороны это будет дополнительное напряжение для уходящей команды (да и для бизнеса), причин (почему проект не был передан в необходимом объеме) может быть много.
Они будут нервничать и / или могут сделать только видимость передачи проекта в полном объеме (получим обещанную премию, а дальше трава не расти..) или сразу опустят лапки (если их уже охватило уныние :)).
Лучшая мотивация — это осознание того, что твою работу не выбросят на помойку, что ты тратил бесценное время не зря. Для этого, опять же, нужно стараться делать все так, чтобы не было стыдно передать его другим людям и помнить что никто не идеален, часто новый взгляд на ситуацию — только на пользу делу. Если радеешь за дело, то с радостью поможешь новой команде.
Это конечно идеальные варианты, но мир такой, каким Мы его делаем.
Возможно просто разница в квалификациях вашей и их
Да, опыт у всех разный, я это понимаю. Как понимаю что и у меня не сразу получалось хорошо. На то он и опыт…
Может позже они бы и рады были всё переписать по уму, но время на это не давали.
Тут уже больше от бизнеса зависит и от их взаимодействия с командой; если проект важный, то все вместе они были обязаны найти выход и направить свою деятельность на улучшение ситуации.
А почему вы не инициировали обсуждение? И вы не думаете, что та команда могла просто не считать проблемой то, что вы считаете?
Инициация обсуждения с моей стороны выглядела бы как — объясните мне то, не знаю что, так, не знаю как). Полным представление о проекте обладает команда, которая его делала. И именно ей следовало по порядку рассказать что это, как работает, какие цели преследует, чем помогает, что требует постоянного внимания, какие есть известные проблемы, какие мысли на будущее развитие и улучшения. Человека нужно погружать в образ, иначе со стороны команды это выглядит как попытка залездь в их голову и такой подход с самого начала взаимодействия не предвещает ничего доброго)))
«откроет код и за 5 минут разберётся»?
Легко, при условии что виден весь образ проекта. Иначе это похоже на чтение вырванных из контекста мыслей, и как учит нас СМИ, допридумывания этой информации ограничено лишь фантазией))
Если резюмировать: необходимо видеть всю картину проекта и относиться к партнерам по-человечески, делая свою работу.
Спасибо за ответ!)
Опять же, если команда знает, что уходит, зачем ей напрягаться и что то вам делать? Команду мотивировали на это?
Не знаю, мотивировали или нет, но разве брать ответственность за свой проект — это плохо? Уходя на новую работу я предпочитал передать все знания по проекту, все особенности и тонкости. Хотел чтобы целостный образ системы был в голове у того, кто будет ей заниматься дальше. Иначе то, над чем я так долго трудился, вкладывал силы и душу, будет размазано по грязной дороге жизненного цикла программы :) (и грязная она потому, что там размазано немало проектов)
На счет ресурсов — да, иногда бывает нужно правильно расставить приоритеты и от многого отказаться. Но бывает достаточно перед началом проекта очень хорошо подумать, штурмовать задачу, сформировать целостный образ — тогда все получится сделать. В некоторых случаях у меня на штурм уходило до 80% времени, которое по факту требовалось для выхода проекта в пилот. Остальное время писал код..)
Пример не из области программирования
Да, достаточно часто встречается такое. Думаю в каждом конкретном случае можно было по-человечески договориться и страдать не пришлось бы ни работодателю, ни работнику.
Сам бывал в таких ситуациях, сейчас понимаю что в некоторых случаях мог подвести ожидания работодателя, но им не стоило забывать про бас-фактор, я всегда был готов заниматься с «запасным» человеком, но его не было))
близок к идеалу
К этому можно стремиться
криворукие гамадрилы
Такие, наверно, тоже бывают, но если стараться, то руки выпрямятся, и гамадрил эволюционирует)))
Команда умных и адекватных людей может быстро превратиться в свою противоположность, если этих людей перегрузить задачами до выгорания.
Да, и такое бывает. Относись к ним по человечески, к их труду и получишь счастливых людей, осознающих свою роль, которые и без давления «сверху» понимают, что они важны (т.к. видят всю картину происходящего и не строят иллюзий).
Получилось немного лично и субъективно, но никому не навязываю)
Спасибо за ответ!)
С чем то похожим недавно имел дело.
Команда несколько лет разрабатывала внутренний продукт и сейчас почти все разбежались, а мы, «новички на проекте», разгребаем. Судя по всему, начиная от кода, подходов и выбранных «фреймворков» до процессов CI — на проекте делалось все, чтобы сделать его как можно сложнее, запутаннее, и сохранить как можно больше уникальных знаний о «костылях», зарытых в кучу «Г» (ИМХО).
Сейчас мне очевидно (разобравшись глубже во всем проекте и процессах), что многие вопросы, проблемы и нюансы можно было обсудить, пока команда была еще с нами. Со многими проблемами можно было разобраться быстро, если бы ушедшая команда была действительно в этом заинтересованна.
Часто понимал что мне просто не договаривают о том, что прямо или косвенно касается выполнения моих непосредственных задач.
Впрочем, возможно, не стоит приписывать злонамеренность там, где можно объяснить все простой глупостью.
P/S/ Сейчас команда состоит из умных и адекватных людей, с которыми приятно работать. А проект живет, и, возможно, еще поцветет))
Замечательная статья, спасибо!
Сам в последнее время думал над проблемами последствий автоматизации и замещения людей роботами (в тч программами) — по мне так если будут разумные роботы, то каждый кто имеет существенный опыт в своем деле может купить (за счет гос-ва) себе разумного робота болванку (программу), обучить его всему что знает и уехать куда-нить на бора-бора, пока тот отрабатывает свою стоимость и зарабатывает зарплату для этого человека)) При этом человека нельзя уволить, тк он и не работает) и если обученная программа будет копироваться в другие инстансы, то получать еще деньги плюсом за это) Может получиться здоровая конкуренция — мол мой робот обучен лучше, испытайте или доводите «до ума» своего))
«Трудно быть богом» — даже от воспоминаний прослушивания волосы дыбом встают, очень нравится как передали атмосферу: звуки, музыка, интонации…
«Обитаемый остров» тоже очень понравился.
Еще нравится «Автостопом по галактике» — слушал первые 3 книги.
Они будут нервничать и / или могут сделать только видимость передачи проекта в полном объеме (получим обещанную премию, а дальше трава не расти..) или сразу опустят лапки (если их уже охватило уныние :)).
Лучшая мотивация — это осознание того, что твою работу не выбросят на помойку, что ты тратил бесценное время не зря. Для этого, опять же, нужно стараться делать все так, чтобы не было стыдно передать его другим людям и помнить что никто не идеален, часто новый взгляд на ситуацию — только на пользу делу. Если радеешь за дело, то с радостью поможешь новой команде.
Это конечно идеальные варианты, но мир такой, каким Мы его делаем.
А по жизни и в душе я инженер-программист))
Да, опыт у всех разный, я это понимаю. Как понимаю что и у меня не сразу получалось хорошо. На то он и опыт…
Тут уже больше от бизнеса зависит и от их взаимодействия с командой; если проект важный, то все вместе они были обязаны найти выход и направить свою деятельность на улучшение ситуации.
Инициация обсуждения с моей стороны выглядела бы как — объясните мне то, не знаю что, так, не знаю как). Полным представление о проекте обладает команда, которая его делала. И именно ей следовало по порядку рассказать что это, как работает, какие цели преследует, чем помогает, что требует постоянного внимания, какие есть известные проблемы, какие мысли на будущее развитие и улучшения. Человека нужно погружать в образ, иначе со стороны команды это выглядит как попытка залездь в их голову и такой подход с самого начала взаимодействия не предвещает ничего доброго)))
Легко, при условии что виден весь образ проекта. Иначе это похоже на чтение вырванных из контекста мыслей, и как учит нас СМИ, допридумывания этой информации ограничено лишь фантазией))
Если резюмировать: необходимо видеть всю картину проекта и относиться к партнерам по-человечески, делая свою работу.
Спасибо за ответ!)
Не знаю, мотивировали или нет, но разве брать ответственность за свой проект — это плохо? Уходя на новую работу я предпочитал передать все знания по проекту, все особенности и тонкости. Хотел чтобы целостный образ системы был в голове у того, кто будет ей заниматься дальше. Иначе то, над чем я так долго трудился, вкладывал силы и душу, будет размазано по грязной дороге жизненного цикла программы :) (и грязная она потому, что там размазано немало проектов)
На счет ресурсов — да, иногда бывает нужно правильно расставить приоритеты и от многого отказаться. Но бывает достаточно перед началом проекта очень хорошо подумать, штурмовать задачу, сформировать целостный образ — тогда все получится сделать. В некоторых случаях у меня на штурм уходило до 80% времени, которое по факту требовалось для выхода проекта в пилот. Остальное время писал код..)
Да, достаточно часто встречается такое. Думаю в каждом конкретном случае можно было по-человечески договориться и страдать не пришлось бы ни работодателю, ни работнику.
Сам бывал в таких ситуациях, сейчас понимаю что в некоторых случаях мог подвести ожидания работодателя, но им не стоило забывать про бас-фактор, я всегда был готов заниматься с «запасным» человеком, но его не было))
К этому можно стремиться
Такие, наверно, тоже бывают, но если стараться, то руки выпрямятся, и гамадрил эволюционирует)))
Да, и такое бывает. Относись к ним по человечески, к их труду и получишь счастливых людей, осознающих свою роль, которые и без давления «сверху» понимают, что они важны (т.к. видят всю картину происходящего и не строят иллюзий).
Получилось немного лично и субъективно, но никому не навязываю)
Спасибо за ответ!)
Команда несколько лет разрабатывала внутренний продукт и сейчас почти все разбежались, а мы, «новички на проекте», разгребаем. Судя по всему, начиная от кода, подходов и выбранных «фреймворков» до процессов CI — на проекте делалось все, чтобы сделать его как можно сложнее, запутаннее, и сохранить как можно больше уникальных знаний о «костылях», зарытых в кучу «Г» (ИМХО).
Сейчас мне очевидно (разобравшись глубже во всем проекте и процессах), что многие вопросы, проблемы и нюансы можно было обсудить, пока команда была еще с нами. Со многими проблемами можно было разобраться быстро, если бы ушедшая команда была действительно в этом заинтересованна.
Часто понимал что мне просто не договаривают о том, что прямо или косвенно касается выполнения моих непосредственных задач.
Впрочем, возможно, не стоит приписывать злонамеренность там, где можно объяснить все простой глупостью.
P/S/ Сейчас команда состоит из умных и адекватных людей, с которыми приятно работать. А проект живет, и, возможно, еще поцветет))
Сам в последнее время думал над проблемами последствий автоматизации и замещения людей роботами (в тч программами) — по мне так если будут разумные роботы, то каждый кто имеет существенный опыт в своем деле может купить (за счет гос-ва) себе разумного робота болванку (программу), обучить его всему что знает и уехать куда-нить на бора-бора, пока тот отрабатывает свою стоимость и зарабатывает зарплату для этого человека)) При этом человека нельзя уволить, тк он и не работает) и если обученная программа будет копироваться в другие инстансы, то получать еще деньги плюсом за это) Может получиться здоровая конкуренция — мол мой робот обучен лучше, испытайте или доводите «до ума» своего))
«Обитаемый остров» тоже очень понравился.
Еще нравится «Автостопом по галактике» — слушал первые 3 книги.