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

Причем прилетает все мне, команду я из под удара увожу. Но хочется с этим что-то сделать.
Есть способ это как-то отработать?

Знаю, что здесь много грамотных управленцев. Сам только начинаю.

Здравствуйте, __SPIRIT__, Вы писали:

__S>Знаю, что здесь много грамотных управленцев. Сам только начинаю.
А команда участвует в оценке работ? Если да — почему они не возражают/их не слышат?

Если нет — на что опирается менеджер при расчёте сроков?

Здравствуйте, Sinix, Вы писали:

__S>>Знаю, что здесь много грамотных управленцев. Сам только начинаю.
S>А команда участвует в оценке работ? Если да — почему они не возражают/их не слышат?
S>Если нет — на что опирается менеджер при расчёте сроков?

Бывает участвует, бывает нет. Проблема не в этом, менеджера вообще могут не спросить. Пример из последнего:
СТО перепутал дату окончания эстимирования с датой релиза. И успел пообещать до того как мы с ним это обсудили.
В такой ситуации можно конечно упереться рогом, но контракт будет под угрозой.

30.10.2013 15:20, __SPIRIT__ пишет:

> В такой ситуации можно конечно упереться рогом, но контракт будет под
> угрозой.
И что? Как это отразится на тебе?

Здравствуйте, __SPIRIT__, Вы писали:

__S>Бывает участвует, бывает нет. Проблема не в этом, менеджера вообще могут не спросить. Пример из последнего:

Угу, т.е. проблема не столько в планировании, сколько в отсутствии связи между собственно исполнителями и cto, печально

Заочно ничего хорошего не посоветовать, но, если есть возможность общаться напрямую — нужно договариваться и вести к тому, чтобы сроки/задачи на каждую итерацию согласовывались с командой.

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

Здравствуйте, Vzhyk, Вы писали:

>> В такой ситуации можно конечно упереться рогом, но контракт будет под
>> угрозой.

V>И что? Как это отразится на тебе?

не будет новых контрактов => не будет увлечения бюджета.
А нам люди очень нужны...

30.10.2013 16:30, __SPIRIT__ пишет:

> не будет новых контрактов => не будет увлечения бюджета.
> А нам люди очень нужны...
Ну тогда терпи и нивелируй ляпы СТО. Я не вижу путей воздействия, кроме
как договориться с еще более высоким начальством, настучать на этого и
сверху СТО воспитают.

Здравствуйте, Sinix, Вы писали:

__S>>Бывает участвует, бывает нет. Проблема не в этом, менеджера вообще могут не спросить. Пример из последнего:

S>Угу, т.е. проблема не столько в планировании, сколько в отсутствии связи между собственно исполнителями и cto, печально

И в планировании тоже. Пример:
внешний дэдлайн 30, мы отдаем версию 25. Сегодня 30 билд еще не скачан. Завтра скорее всего опять что-то разгорится.

S>Заочно ничего хорошего не посоветовать, но, если есть возможность общаться напрямую — нужно договариваться и вести к тому, чтобы сроки/задачи на каждую итерацию согласовывались с командой.

Я с ним в постоянном контакте. Но вот о чем можно договорится чтобы исправить ситуацию?

S>Разумеется, с конкретной раскладкой по паре-тройке случаев: срок назван такой-то, выпустили тогда-то, пришлось переработать столько-то. Плюс последствия — технический долг вырос, команда устала и не доверяет менеджеру/начальству, шансы сорвать следующую итерацию выше. Ну, и предложения как исправлять (тут, опять-таки, без знания конкретики ничего полезного не предложишь).

Формально мы почти всегда успеваем, но все впопыхах. Как результат регулярно что-то стреляет на продакшене(не критичное но неприятное).
Хочется перевести этот процесс в спокойное русло.

Здравствуйте, Vzhyk, Вы писали:

>> не будет новых контрактов => не будет увлечения бюджета.
>> А нам люди очень нужны...
V>Ну тогда терпи и нивелируй ляпы СТО. Я не вижу путей воздействия, кроме
V>как договориться с еще более высоким начальством, настучать на этого и
V>сверху СТО воспитают.

Это революционные методы. В данной ситуации неприменимы абсолютно. Хочется эволюционного решения проблем.

Здравствуйте, __SPIRIT__, Вы писали:

__S>Я с ним в постоянном контакте. Но вот о чем можно договорится чтобы исправить ситуацию?
О, тогда легче Разумеется, всё что ниже — выстрел наощупь, может помочь, может нет.

Ход мыслей примерно следующий:

1. Никогда не начинать с взаимных обвинений. Вроде очевидно, но я наелся последствий, причём с обоих сторон Поэтому за все проблемы, что были раньше — амнистия, но сами проблемы не забываются, а используются как примеры для последующих пунктов.

2. Обосновывается необходимость внести изменения в стиль работы, доводы — см. пункт выше. Если человек признал, что надо менять процесс — закрепляем в виде договорённости, если человек может потом поменять своё мнение — желательно при свидетелях.

3. После того, как получили согласие на "да, нужно решать проблему" — совместно с CTO составляем и подписываем регламент взаимодействия. Если отбросить пафос — это обычная бумажка A4, на которой перечислены (кратко!) основные этапы на всю итерацию (или хотя бы на конец итерации), ну, например:

---

Контроль за состоянием релиза:
CTO, тимлид Каждую пятницу в 15:00 проводится пятиминутка.
Тимлид — озвучивает текущее состояние по итерации: что поменялось с прошлой пятиминутки, оценка сроков.
CTO — зафиксировал, пообещал исправить всё, что от него зависит

Тимлид При возникновении возможных задержек, если срок сдвига больше двух дней: тимлид оповещает CTO о возможном изменении сроков.

CTO При необходимости озвучить сроки: если CTO извещён о сдвигах — предварительно консультируется с тимлидом. Не извещён — используются оценки с прошлой пятиминутки

---

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

4. (самое сложное) Работаем по регламенту


__S>Формально мы почти всегда успеваем, но все впопыхах. Как результат регулярно что-то стреляет на продакшене(не критичное но неприятное).
__S>Хочется перевести этот процесс в спокойное русло.

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

Разумеется, нужно будет скорректировать сроки/приоритеты, чтобы важнейшие задачи не попадали на конец итерации.

Здравствуйте, __SPIRIT__, Вы писали:

__S>Причем прилетает все мне, команду я из под удара увожу. Но хочется с этим что-то сделать.

Для начала, почему у вас вообще CTO занимается оперативными планами если в норме это не его зона ответственности?

__S>Есть способ это как-то отработать?

Расскажи ему про сетевое планирование и метод трех оценок. Если не поможет, найми ему секретаршу, которая будет следить за планами и не позволять ему давать нереальные обещания.

__S>не будет новых контрактов => не будет увлечения бюджета.
__S>А нам люди очень нужны...

Это и есть корень шизофреничности сложившейся ситуации. CTO вынужден обманывать, чтобы добиться требуемого результата (новые контракты).
Вам следует решить, какая перспектива больше нравится:
* спокойная работа без пожаров и авралов, но и без новых контрактов, расширения команды и увеличения притока денег
* напряженная работа, регулярные авралы и переработки — но с притоком людей и бюджетов

Ситуация классическая донельзя. Вряд ли вам кто-то сможет помочь на форуме. Можно лишь дать некие общие рекомендации. В первую очередь, осознать, что вы с СТО в одной лодке. Сесть за кружкой пива (или что у вас применяется для неформальной беседы), поговорить. Понять друг друга. Понять, что у него (СТО) тот же выбор — спокойная работа vs приток бюджета.

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

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

01.11.2013 2:11, SkyDance пишет:

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

Здравствуйте, __SPIRIT__, Вы писали:

__S>Есть проект, есть отличная команда. Есть CTO, который как написано в сабже, абсолютно не умеет планировать, из-за чего регулярно устраивает пожары на проекте.
__S>Он все всегда делает в последний момент, как результат вылетает за свои дедлайны. В результате регулярные пожары и работа ночами.
__S>Регулярно обещает нереальные и абсолютно нереальные сроки. В результате регулярные пожары и работа ночами.
__S>и т.п.

__S>Причем прилетает все мне, команду я из под удара увожу. Но хочется с этим что-то сделать.
Это очень правильно. Остальное приобретается с опытом. Придет время и собирать камни.

По остальному, мне в целом понравился ответ SkyDance. Очевидно, что надо менять механизм подписания контракта. Но решение сильно зависит от ситуации. Могу предположить, что ваш CTO не очень опытен в ведении переговоров с заказчиками и продавливается под нереальные сроки. В этом случае можно договориться, что на переговоры вы ходите вдвоем и решение о сроках тоже принимаете вдвоем.

Здравствуйте, __SPIRIT__, Вы писали:

__S>Регулярно обещает нереальные и абсолютно нереальные сроки. В результате регулярные пожары и работа ночами.

Не работать по ночам? Просто если вы успеваете, то почему бы ему и не продавать дальше также.

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

Здравствуйте, __SPIRIT__, Вы писали:

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

А вы умеете? Или мб кто-то другой в этой истории умеет? Вот туда и надо передать эту функцию, преподнеся это CTO этично. Например, что он будет заниматься более важными, стратегическими вопросами. Тем более вдруг действительно будет. Такая передача функций пройдет нормально, если CTO:
1) согласен с позицией неумелое планирование -> пожары
2) не устраивают пожары
Если нет 1ого — то обсуждать, мб и вы не правы. Если нет 2ого — то это не такой уж и редкий случай и это печально.

я бы сказал, что если CTO не умеет планировать, а еще потом и авралы устраивает вместо самостоятельной подачи в отставку — это уже не CTO, а клоун
потому что основная функция CTO — это как раз таки планирование

T>потому что основная функция CTO — это как раз таки планирование

Попробуйте расшифровать аббревиатуру CTO и посмотреть значение составляющих слов.

Здравствуйте, SkyDance, Вы писали:

T>>потому что основная функция CTO — это как раз таки планирование

SD>Попробуйте расшифровать аббревиатуру CTO и посмотреть значение составляющих слов.


в маленькой компании, где нет промежуточного уровня между CTO и разработчиками, и где это второй человек после CEO — его основная функция именно в планировании, распределении работы и установке приоритетов

Здравствуйте, __SPIRIT__, Вы писали:

__S>Он все всегда делает в последний момент, как результат вылетает за свои дедлайны. В результате регулярные пожары и работа ночами.
Это такой метод стимулирования, держит команду в тонусе. Скорее всего, дело не в нём, а в руководстве компании. А разносы устраивают что бы премию не платить за хорошую работу.
Не исключаю, что где-нибудь в компании манагеров ваш СТО хвастается тем, как он вас построил, смеётся над вами, лохами. Он — СПЕЦИАЛИСТ, в вы — МАЛЬЧИКИ.