Давай я тебе расскажу в стиле ответов топ-топ менеджмента некоторой конторы.

>Были какие задачи?

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

> Как устроено планирование, как устроена приоритизация задач, кто принимает решение, какой горизонт планирования?

Ну, сам понимаешь, мы тебя и взяли как раз чтобы ты всё организовал. У нас были все таски в Redmine/Jira, ну вот по таскам всё ОК, проект типа готов, так что вот месяц на органзацию, и покажи себя. Мы не даём простых задач, бла-бла-бла.

> В какой мере у команды разработчиков есть право на самоопределение?

Ну, у нас тут аджайл, да.

Смотри: идти в такую историю имеет смысл только тогда, когда топ-топ менеджмент понимает, что ты пришёл тушить ему пожар. Если не понимает, тогда идти не надо — на фуллтайм так точно, и даже насчёт “идти под проект миграции” я бы десят раз подумал (возвращаемся к вопросу про стрелочника)

>у нас тут аджайл
>наняли, чтобы ты все организовал

Жизненно

> Ну, у нас тут аджайл, да.

Аджайл — это в данном случае как у Дилберта? Менеджер имеет право в любой момент прибежать со своими срочными задачами, в остальном ничего не меняется?

> Мы не даём простых задач

Видимо, дают долю, ну-ну.

Там не пожар. Там созданный дефицит времени из-за неспособности управлять командой.

Это не лечится тушением пожара, так как ничего не горит. Это лечится постановкой процесса. А чтобы его ставить, нужно время и движение небольшими шагами. Потому что странно ожидать, что если люди год-два-три жили расслаблено, они за неделю соберутся и всё сделают.

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

Именно)

Смотри. Даже здесь есть граждане, которые не понимают, что из 4-х человек нельзя сделать саппорт 24*7/365. А ты про то, что люди, столкнувшиеся с разработкой, что-то сразу поймут и будут делать не так, как хочется в стиле чайка-менеджмента, а по процессам.

Долбаная маковская клавиатура.

Бьётся нормально. Ну, бывает такое в жизни, что CEO или, чаще, инвестор посмотрел и понял: в компании задница, нужно не кровати переставлять, а этих, как их, сотрудников менять. Но просто чтобы их менять, нужно убедиться, что ты сезон переживёшь, поэтому задачи есть краткосрочные и есть долгосрочные. Нужно убедиться, что ты сможешь ставить и те, и другие.

Хороший признак — если прямо перед тобой там произошли организационные изменения не по направлению CTO, например, инвестор заменил CEO или что-нибудь такое. Второй хороший признак — как с тобой общаются, да.

Я скорее про ситуацию, когда есть какой-то ключевой стейкхолдер, который год-два не погружался в процессы компании, а потом погрузился и охренел.

Что-то все остальные как-то умолкли )

> Но просто чтобы их менять, нужно сезон пережить, поэтому задачи есть краткосрочные и есть долгосрочные

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

Если оно работало, то оставьте всё как есть и не трогайте. Иначе потом придётся в проде крутить новую систему. А она не будет работать сразу так, как надо. Это аксиома, блин.

Соответственно, задача управленца - донести эту мысль до заказчика. Если у него есть аргументы отличные от сдачи к XXVI съезду КПСС, то надо понять, что принесёт минимум убытка.

И - да. Суметь объяснить, что не стоит вопрос потери денег. Стоит вопрос минимизации потерь.

Я себе представил ситуацию, когда изменений уже неважно сколько, потому что, например, прод критично зависит от какого-то внешнего источника данных, который end of API v1 life с 1 февраля. И мигрировать старую систему на новое API стоит примерно столько же, сколько вытащить на прод новую.

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

А она может не вывезти, внезапно.

Ну потому что такое условие хоть как-то оправдывает постановку задачи “выкатить 5 месяцев за 1 с полной миграцией всего”

А так, конечно, надо понимать, что там конкретно за исходное требование

> И мигрировать старую систему на новое API стоит примерно столько же, сколько вытащить на прод новую.

Это вероятно, конечно. Но именно это и надо узнать.

Ага.

мне сегодня ссылку на статью на хабре скинули, про разработчиков, https://m.habr.com/ru/post/483592/ что вы думаете о теме статьи? это троллинг/наброс или вы согласны с ней?