На моем опыте был случай, когда один такой дешевый разработчик озаботился джобсекьюрити и перестал пускать кого-либо вообще в свою часть проекта. В итоге эта его часть стала самой проблемной, а он соответственно – самым продуктивным, так как эти проблемы постоянно решал. Его часть проекта была довольно критичной для заказчика, так что предложения по переработке от более дорогих разработчиков отбивались со словами "я пока занят" и "вы без меня все сломаете". В итоге проект растянулся в полтора раза и это перекрыло всю "экономию" на квалифицированных разработчиках.
На мой взгляд, в планировании должен участвовать разработчик, чтобы не получилась ситуация, когда сроки спускают сверху, а команда должна перерабатывать, чтобы в них уложиться. Менеджер не может знать все тонкости разработки. Много раз встречал такую ситуацию: руководство считает, что "надо всего одну проверку поменять", а на самом деле это требует создания совершенно нового функционала. В итоге для внедрения изменения надо все сроки сдвинуть каскадом или заставить команду работать сверхурочно. По моему опыту выбирают второе.
Но разработчика лучше на планирование слишком часто не отвлекать, так что делать его стоит по заранее оговоренному расписанию. А в качестве такого расписания как раз подходят спринты.
Канбан-доска – хорошее решение, но немного для других целей. Она хороша для синхронизации людей внутри команды и распределения задач. А планирование, как мне кажется, должно синхронизировать команду и менеджмент.
Спринты не так уж и плохи, если нет необходимости соблюдать бюрократические формальности с закрытием всех задач в конце и чрезмерным разбиением на подзадачи. Они структурируют процесс планирования в проектных командах: вместо абстрактной задачи "распланировать реализацию такой-то информационной системы", можно верхнеуровнево распределить задачи по выведению различного функционала и детально расписать только ближайшие поставки. Короче – это удобный фреймворк для планирования методом набегающей волны.
А без самого планирования в проектной разработке никак – PM должен выбить бюджет на заранее определенный срок.
По поводу "не дурачки писали" – так можно почти про все распространенные IT технологии сказать. На мой взгляд важно понимать, как они устроены, чтобы понимать, как ими пользоваться, и выбирать то, что больше подходит для конкретной задачи. Я думаю, разработка в ближайшем будущем будет эволюционировать в эту сторону с развитием ИИ.
Сейчас это модно называть словом bus-фактор, вроде. Его многие недооценивают, потому что это выглядит дешево сначала – один человек работает за целую команду. Но со временем даже небольшое изменение нагрузки/требований начинает стоить очень дорого:
Переработку может сделать в адекватные сроки только один человек;
Этот один человек может быть уже занят другими изменениями, которые тоже может быстро сделать он один;
Этот один человек может заболеть или уволиться.
По моему опыту эффективно показать человеку, что он может перейти к более интересным задачам, если передаст коллегам свои старые наработки.
На моем опыте был случай, когда один такой дешевый разработчик озаботился джобсекьюрити и перестал пускать кого-либо вообще в свою часть проекта. В итоге эта его часть стала самой проблемной, а он соответственно – самым продуктивным, так как эти проблемы постоянно решал. Его часть проекта была довольно критичной для заказчика, так что предложения по переработке от более дорогих разработчиков отбивались со словами "я пока занят" и "вы без меня все сломаете". В итоге проект растянулся в полтора раза и это перекрыло всю "экономию" на квалифицированных разработчиках.
На мой взгляд, в планировании должен участвовать разработчик, чтобы не получилась ситуация, когда сроки спускают сверху, а команда должна перерабатывать, чтобы в них уложиться. Менеджер не может знать все тонкости разработки. Много раз встречал такую ситуацию: руководство считает, что "надо всего одну проверку поменять", а на самом деле это требует создания совершенно нового функционала. В итоге для внедрения изменения надо все сроки сдвинуть каскадом или заставить команду работать сверхурочно. По моему опыту выбирают второе.
Но разработчика лучше на планирование слишком часто не отвлекать, так что делать его стоит по заранее оговоренному расписанию. А в качестве такого расписания как раз подходят спринты.
Канбан-доска – хорошее решение, но немного для других целей. Она хороша для синхронизации людей внутри команды и распределения задач. А планирование, как мне кажется, должно синхронизировать команду и менеджмент.
Спринты не так уж и плохи, если нет необходимости соблюдать бюрократические формальности с закрытием всех задач в конце и чрезмерным разбиением на подзадачи. Они структурируют процесс планирования в проектных командах: вместо абстрактной задачи "распланировать реализацию такой-то информационной системы", можно верхнеуровнево распределить задачи по выведению различного функционала и детально расписать только ближайшие поставки. Короче – это удобный фреймворк для планирования методом набегающей волны.
А без самого планирования в проектной разработке никак – PM должен выбить бюджет на заранее определенный срок.
Рад стараться)
По поводу "не дурачки писали" – так можно почти про все распространенные IT технологии сказать. На мой взгляд важно понимать, как они устроены, чтобы понимать, как ими пользоваться, и выбирать то, что больше подходит для конкретной задачи. Я думаю, разработка в ближайшем будущем будет эволюционировать в эту сторону с развитием ИИ.
Сейчас это модно называть словом bus-фактор, вроде. Его многие недооценивают, потому что это выглядит дешево сначала – один человек работает за целую команду. Но со временем даже небольшое изменение нагрузки/требований начинает стоить очень дорого:
Переработку может сделать в адекватные сроки только один человек;
Этот один человек может быть уже занят другими изменениями, которые тоже может быстро сделать он один;
Этот один человек может заболеть или уволиться.
По моему опыту эффективно показать человеку, что он может перейти к более интересным задачам, если передаст коллегам свои старые наработки.