M>Я тимлид первой команды. Как думаете есть смысл соглашаться браться? M>И на каких условиях?
Переписывать на свою платформу. Если она у вас, конечно, есть.
Здравствуйте, merge, Вы писали:
M>В компании идут 2 паралелльных больших проекта.
M>Одна команда достаточно неплохо ведет проект, на вторую много жалоб от кастомеров и жалобы только увеличиваются.
Есть ли уверенность что проблема не в кастомерах?
M>И вот начальство хочет на более успешную команду кинуть задачи с менее успешной.
Почему начальство считает что кинув команду с успешного проекта — не загубит первый, вытащив второй?
M>Насколько я понял, что в менее успешной команде проблема в проджекте, который часто неверно излагает бизнес нидс и программисты часто переделывают.
Есть ли 100% уверенность?
Сделайте анализ текущей ситуации, откуда именно идет не довольство — много багов в новых функциях, новые функции не удобные, новые функции не достаточно проработаны, или сделаны не так как оговаривалось, клиенты не приходят на митинги демо, не делают UAT, etc. Причин может быть много, доходя до совсем глупых что внутри компании клиента намечается реструктуризация и сейчас отдел один страдает и пытается сказать что проблемы идут от софта, или просто пользователи перегружены.
В любом случае без четкого понимания ландшафта проблемы бежать и помогать с закрытием багов наверное будет сложно и можно принести больше вреда чем пользы.
Здравствуйте, merge, Вы писали:
M>В компании идут 2 паралелльных больших проекта.
M>Одна команда достаточно неплохо ведет проект, на вторую много жалоб от кастомеров и жалобы только увеличиваются. M>И вот начальство хочет на более успешную команду кинуть задачи с менее успешной. M>Насколько я понял, что в менее успешной команде проблема в проджекте, который часто неверно излагает бизнес нидс и программисты часто переделывают.
M>Предварительно догооврились, если возьмемся, то помогать только с техническими задачами, без бизнес логики особой. M>Я тимлид первой команды. Как думаете есть смысл соглашаться браться? M>И на каких условиях?
Начинать надо с выкидывания менеджера второй команды на мороз. Вместе с тим-лидом. Потом выборочно, под лупой-рассмотреть оставшуюся команду. И только затем уже поразмышлять, а ввязываться ли в это говно.
В остальных случаях, даже в случае героического успеха-все плюшки поднимут менеджер и тим-лид второй команды.
Проверено(с)
H>Начинать надо с выкидывания менеджера второй команды на мороз. Вместе с тим-лидом. Потом выборочно, под лупой-рассмотреть оставшуюся команду. И только затем уже поразмышлять, а ввязываться ли в это говно. H>В остальных случаях, даже в случае героического успеха-все плюшки поднимут менеджер и тим-лид второй команды. H>Проверено(с)
это при условии, что проблема была реально в менеджере. А то окажется, что проблема в том, что у клиентов много противоречивых требований, сроки сжатые, а денег платят намного больше, чем первая успешная команда на своем проекте приносит. И окажешься в результате на морозе вместе со всей конторой
M>И вот начальство хочет на более успешную команду кинуть задачи с менее успешной. M>Насколько я понял, что в менее успешной команде проблема в проджекте, который часто неверно излагает бизнес нидс и программисты часто переделывают. M>Предварительно догооврились, если возьмемся, то помогать только с техническими задачами, без бизнес логики особой. M>Я тимлид первой команды. Как думаете есть смысл соглашаться браться? M>И на каких условиях?
Хм. Может для начала подключиться на организационном уровне — как второй тимлид без привлечения разработчиков — на мой взгляд для начала стоит понять действительную проблему. Если проблема в заказчиках, что здесь увеличение ресурсов разработки ничего не даст — сколько туда не влей. Если проблема в том, что второй тимлид не умеет работать с заказчиками — возможное решение прокачать тимлида. Может проблема вообще в качестве кода и от вас потребуется кодревью и настройка там тестирования.
Т.е. прежде чем под что-то подвязываться (и тем более подвязывать свою команду), имхо, стоит понять — а может оно ничего не даст, кроме геморроя.
Кстати, может если удастся решить вопрос с потоком хотелок от бизнеса и обратной связью, то может и при существующей работе второй команды бизнес будет более удовлетворен.
А если удастся решить без привлечения команды — то плюшек от этого можно получить даже больше
P.S. есть оценка — насколько просядет ваш проект, если выделите время на помощь? Ваши заказчики на это согласны?
Здравствуйте, merge, Вы писали:
M>В компании идут 2 паралелльных больших проекта.
M>Одна команда достаточно неплохо ведет проект, на вторую много жалоб от кастомеров и жалобы только увеличиваются. M>И вот начальство хочет на более успешную команду кинуть задачи с менее успешной. M>Насколько я понял, что в менее успешной команде проблема в проджекте, который часто неверно излагает бизнес нидс и программисты часто переделывают.
M>Предварительно догооврились, если возьмемся, то помогать только с техническими задачами, без бизнес логики особой. M>Я тимлид первой команды. Как думаете есть смысл соглашаться браться? M>И на каких условиях?
Чтобы "вытащить" проект надо лезть во все, в предметную, планирование, управление требованиями, тестирование и т.д..
Самое лучшее условие, это процент от прибыли с проекта. Тогда можно влезать по самые уши.
Здравствуйте, Vlad_SP, Вы писали:
V_S>Здравствуйте, achmed,
A>>Самое лучшее условие, это процент от прибыли с проекта.
V_S>"Съесть то он съесть, да хто ж ему дасть?" (ц)
Почему бы и нет, если есть потребность, то должны быть готовы делиться. Это деловой подход.
Просто о подобной практике мало кто знает из рядовых сотрудников, т.к. доля дается только одному или нескольким участникам проекта.
Здравствуйте, Hardballer, Вы писали:
H>Здравствуйте, merge, Вы писали:
M>>В компании идут 2 паралелльных больших проекта.
M>>Одна команда достаточно неплохо ведет проект, на вторую много жалоб от кастомеров и жалобы только увеличиваются. M>>И вот начальство хочет на более успешную команду кинуть задачи с менее успешной. M>>Насколько я понял, что в менее успешной команде проблема в проджекте, который часто неверно излагает бизнес нидс и программисты часто переделывают.
M>>Предварительно догооврились, если возьмемся, то помогать только с техническими задачами, без бизнес логики особой. M>>Я тимлид первой команды. Как думаете есть смысл соглашаться браться? M>>И на каких условиях? H>Начинать надо с выкидывания менеджера второй команды на мороз. Вместе с тим-лидом.
Непонятно кому и как это донести?
Кастомеру или своем рук-ву?
Как сказать почему не хочу ввязываться если этого не будет?
Здравствуйте, achmed, Вы писали:
A>Здравствуйте, merge, Вы писали:
M>>В компании идут 2 паралелльных больших проекта.
M>>Одна команда достаточно неплохо ведет проект, на вторую много жалоб от кастомеров и жалобы только увеличиваются. M>>И вот начальство хочет на более успешную команду кинуть задачи с менее успешной. M>>Насколько я понял, что в менее успешной команде проблема в проджекте, который часто неверно излагает бизнес нидс и программисты часто переделывают.
M>>Предварительно догооврились, если возьмемся, то помогать только с техническими задачами, без бизнес логики особой. M>>Я тимлид первой команды. Как думаете есть смысл соглашаться браться? M>>И на каких условиях?
A>Чтобы "вытащить" проект надо лезть во все, в предметную, планирование, управление требованиями, тестирование и т.д..
A>Самое лучшее условие, это процент от прибыли с проекта. Тогда можно влезать по самые уши.
это внутренний проект для другого подразделения. непонятно как определяется процент
Здравствуйте, merge, Вы писали:
A>>Чтобы "вытащить" проект надо лезть во все, в предметную, планирование, управление требованиями, тестирование и т.д..
A>>Самое лучшее условие, это процент от прибыли с проекта. Тогда можно влезать по самые уши.
M>это внутренний проект для другого подразделения. непонятно как определяется процент
С этого и надо было начинать. В этом случае договориться наперед о чем то (о повышении) возможно только если у твоего руководителя есть все необходимые полномочия.
