Выглядит так, что вы даже не начали работать, а испугались нагрузки (она тут и правда у нас немаленькая) и ливнули назад в свой теплый мирок.
Про кумовство - категорически не согласен, ерунда. Его, как раз, на порядки меньше, чем любой другой отрасли. Потому что фиг ты родственника посадишь - сами же пишете, что 150 собеседований, а потом еще и работать заставляют :)
Цель статьи - показать самый быстрый способ "вьехать" в почти любой IT проект. Почти - ну потому что у меня максимум было 70-100 чел.
Ясно, что полностью въехать в такое, которое к тому же уже едет, займет полгода. Но нельзя же сидеть полгода, вникая - такого просто никто не даст сделать в коммерческом секторе.
Месяцы и годы слишком долго для решений. Мой подход мне помогал всегда за пару недель дойти до состояния, когда я могу принимать управленческие решения и нести за них ответственность.
:) там раньше было философское. Тут суровый опыт. Каждая строчка имеет несколько историй под собой, еще буду писать про это все, на то и бложик создан :))))
ну слушайте, я привык доверять. При найме обе стороны нуждаются друг в друге и обе решают доверить: компания - свои бабки, работник - свое время.
Я бы не советовал протоколировать в стиле "если вы потом забудете, я вам напомню" - это негативно, а я сторонник позиции be positive, don't be negative. Я записываю всегда со словами: "я могу чтото забыть, важное всегда записываю"
ага, ну когда передаешь и принимаешь проекты часто, поневоле задумаешься :)
я сходил к вам. Мой тезис: когда времени много, можно делать, как угодно. Хоть месяц ковыряться в ТЗ и проектном плане - никто не помешает. Я часто бывал в ситуации, когда дано ничего, сроки горят, все в ужасе и надо быстро принимать решения. Это чистый кризис. И мой список - кризисный. Кризис требует получения минимальной но достаточной для принятия качественных решений информации, оставляя все остальное, менее важное, на потом. Именно поэтому я осознанно не писал про код, про планы развития сотрудников (а просто заменил это парой разговоров). В итоге все это нужно будет (если большой проект), но потом. Сперва - главное.
Мне было важно выделить именно его. За обратку спасибо, список у вас классный!
хороший вопрос. сходу ответ в том, что agile явно не относится к системной интеграции, потому что там есть контракт и заказчику плевать на то, как вы работаете: соберите требования нормально и сдайте :)
но ведь я видел много внутренних команд, которых бизнес задолбал, весь Agile превратился в дырявое ведро, где 70% задач внеплановые (реально). Где там дырка в подходе надо отдельно подумать. Напишу еще :)
про минусы воспринимаю философски: я пришел сюда делиться опытом, а не нести истину в последней инстанции, хорошо когда люди не согласны и рассказывают свой опыт, который другой.
Печально, когда просто молча минусуют. Ну это Хабр, он такой :)
А, вот коллега ниже правильно сказал: я зря отправил статью в хаб "управление разработкой" - оно не туда.
тут смотрите, что важно проговорить. указанные рекомендации я советую применять только в менеджерском общении. Там это важно. В случае общения с командой, уверен, должно быть иначе, там другая коммуникация, у меня есть статья про общение РП и команды, если вы про это. Там - помощник.
Хитрость метода в статье для меня в том, что нет там уязвимой позиции у меня, как у просящего: я проработал проблему, она есть. Сам я ее решить не могу - почему - написано. Я предлагаю несколько вариантов решения, которые вижу и прошу выбрать.
Не хотите выбирать - предложите свое. Не хотите предлагать - я вас задолбаю этим методом и вы потом не сможете никому сказть, что ваш менеджер вас не предупреждал о проблеме.
Я очень много раз сталкивался с манипуляциями, когда меня, как РП, хотели подставить и сделать крайним. Этот метод выручал реально много раз.
ну если при этом все достигают цели - да. И я не вижу отличия от того, что я написал в статье. Потому что когда менеджер предлагает один из вариантов, он сам решает, какие варианты выбрать. В итоге получается то, что вы и написали.
Предлагаю не переходить на обсуждение качества полушарий собеседника ))
если у вас есть опыт - поделитесь, пожалуйста. Как говорится - "критикуя - предлагай". Почему подход, описанный мной вам в ответе выше неэффективен? какой подход лучше, по вашему опыту?
Я, кстати, сейчас без иронии, мне правда интересно, я допускаю, что многого не знаю. Но у меня действительно большой опыт в моей области, который привел вот именно к таким выводам. Не согласны - поделитесь вашим опытом.
а вот тут не согласен. За руководителя РП думать не должен и не может, у него просто нет столько информации для принятия решения. РП должен решать проблемы в рамках своей компетенции - не правда ли?
Так вот пусть и опишет проблему кратко (это очень полезный навык для РП и при работе с заказчиками, в том числе)
Подумает сам (а не я за него), как он сам может это решить (это крайне полезно, переходить из режима "это невозможно" в режим "мне нужно то-то и то-то, чтобы это сделать")
Распишет решения, кратко, сам оценив их
И знаете что - через 5 таких подходов менеджеры учатся решать проблемы самостоятельно, выходя на новый уровень. И это уже переход РП от middle к senior.
Итог: win-win: и руководителю хорошо и РПшнику тоже.
а всего лишь надо немного подумать перед тем как эскалировать
Сперва хотел написать про то, что в растущей компании работы всегда больше чем людей (что всегда дает перегруз, зато и рост для всей команды, измеряемый в опыте и деньгах)...
А сейчас думаю, что без разницы какая команда и какая компания. Способ в статье позволяет сотруднику быстро и четко описать проблему - раз. И пока он это упражнение делает, часто он сам решает задачи и идти никуда не надо - два.
То есть у вас двойная польза: и ребята учатся сами решать вопросы без вас, и у вас гораздо больше времени, а уж на что его потратить - решайте сами
да, согласен, это очень тонкая грань, почти неуловимая и индивидуальная для каждой компании и даже для пары РП-руководитель. Очень старался ее хоть как-то отразить и взял максимально трешовые случаи для того, что РП изменить не может.
спасибо, кеп :) А где в вашем определении определение границы ответственности?
Статья как раз про это. А еще про то, что начинающие РП часто не понимают цену своей договоренности. "должен отвечать" - общие слова.
"не получишь зарплату, потому что мне нечем ее платить" - гораздо более понятно.
"подставишь ГД, потому что он уже пообещал срок, который ты дал" - гораздо более понятно.
Но где граница ответственности тогда? РП не боженька всесильный, он не может изменить все, достигая целей проекта - и помнить об этом РП тоже надо, чтобы сильно не загоняться.
Статья не решает проблему объема/бюджета/рисков. Цель статьи - донести до джунов и тех, кто только еще хочет, понимание того, что РПшникам платят деньги не за то, что они дергают колбаски в Гантте, а совсем за другое. И основное тут для меня - именно ответственность за свои договоренности.
У каждого свой опыт. Вы видели только 2х хороших РП, я видел десятки, из них несколько вырастил лично сам, с нуля. И я знаю, что страшит начинающих РП и знаю проблемы, которыми они грузятся - и большинство моих статей про это.
Про "может изменить" - Я не писал только про риски, неправда ваша :)
про "не может изменить". Я указал там такие случаи:
Расскажите, пожалуйста, ваш опыт про то, что может сделать РП, если проект отменяют без оплаты? Что делать, ваше руководство принуждает РП сделать работы в нереалистичные сроки или не дает команду на это?
К сожалению, в конце просто хамство, вместо конструктива
он никогда не был маленьким. просто в 10х был бум стартапов и кому-то показалось, что команда продуктолог-разработчик отлично решает все-все проблемы любого продукта.
Я даже в популярных ТГ каналах до сих пор слышу апологетов такого подхода. И спорить с ними бесполезно, они просто пока не понимают, что как только продукт начнет расти, понадобится расширять команду и вся эта стройная конструкция опять сведется к так ненавидимому всеми (а зря, кстати) энтерпрайзу
Подумал. Вот 2 основные причины в моем опыте, почему оно не делается:
Заказчик не обладает соответствующими ресурсами для качественного выполнения работ, формирует ТЗ по принципу "как смогла" и выставлет его на тендер. Дальше уже интеграторы "на опыте" смотрят, реалистично сделать то, что в ТЗ или риски слишком велики.
Реактивное управление в компании: решения принимаются внезапно на уровне "ГД сказал сделать" и прдпроектное обследование скатывается в режим "денег заложим, а там что-нибудь придумаем"
В целом, вопрос рисков реализации всем сторонам понятен, потому в стоимость внедрения закладываются дополнительные косты. Судя по тому, что компетенции аналитиков у госзаказчиков (а они - основные заказчики сейчас) не появилось, им дешевле идти путем принятия рисков отсутствия предпроектного обследования
Выглядит так, что вы даже не начали работать, а испугались нагрузки (она тут и правда у нас немаленькая) и ливнули назад в свой теплый мирок.
Про кумовство - категорически не согласен, ерунда. Его, как раз, на порядки меньше, чем любой другой отрасли. Потому что фиг ты родственника посадишь - сами же пишете, что 150 собеседований, а потом еще и работать заставляют :)
Цель статьи - показать самый быстрый способ "вьехать" в почти любой IT проект. Почти - ну потому что у меня максимум было 70-100 чел.
Ясно, что полностью въехать в такое, которое к тому же уже едет, займет полгода. Но нельзя же сидеть полгода, вникая - такого просто никто не даст сделать в коммерческом секторе.
Месяцы и годы слишком долго для решений. Мой подход мне помогал всегда за пару недель дойти до состояния, когда я могу принимать управленческие решения и нести за них ответственность.
да, тут согласен. фиксация договоренностей хороший элемент :)
:) там раньше было философское. Тут суровый опыт. Каждая строчка имеет несколько историй под собой, еще буду писать про это все, на то и бложик создан :))))
ну слушайте, я привык доверять. При найме обе стороны нуждаются друг в друге и обе решают доверить: компания - свои бабки, работник - свое время.
Я бы не советовал протоколировать в стиле "если вы потом забудете, я вам напомню" - это негативно, а я сторонник позиции be positive, don't be negative. Я записываю всегда со словами: "я могу чтото забыть, важное всегда записываю"
ага, ну когда передаешь и принимаешь проекты часто, поневоле задумаешься :)
я сходил к вам. Мой тезис: когда времени много, можно делать, как угодно. Хоть месяц ковыряться в ТЗ и проектном плане - никто не помешает. Я часто бывал в ситуации, когда дано ничего, сроки горят, все в ужасе и надо быстро принимать решения. Это чистый кризис. И мой список - кризисный. Кризис требует получения минимальной но достаточной для принятия качественных решений информации, оставляя все остальное, менее важное, на потом. Именно поэтому я осознанно не писал про код, про планы развития сотрудников (а просто заменил это парой разговоров). В итоге все это нужно будет (если большой проект), но потом. Сперва - главное.
Мне было важно выделить именно его. За обратку спасибо, список у вас классный!
хороший вопрос. сходу ответ в том, что agile явно не относится к системной интеграции, потому что там есть контракт и заказчику плевать на то, как вы работаете: соберите требования нормально и сдайте :)
но ведь я видел много внутренних команд, которых бизнес задолбал, весь Agile превратился в дырявое ведро, где 70% задач внеплановые (реально). Где там дырка в подходе надо отдельно подумать. Напишу еще :)
о, спасибо за замечание. Неправильно было статью слать в хаб "Управление разработкой" как минимум без пояснений. Убрал оттуда
согласен.
про минусы воспринимаю философски: я пришел сюда делиться опытом, а не нести истину в последней инстанции, хорошо когда люди не согласны и рассказывают свой опыт, который другой.
Печально, когда просто молча минусуют. Ну это Хабр, он такой :)
А, вот коллега ниже правильно сказал: я зря отправил статью в хаб "управление разработкой" - оно не туда.
Убрал :)
тут смотрите, что важно проговорить. указанные рекомендации я советую применять только в менеджерском общении. Там это важно. В случае общения с командой, уверен, должно быть иначе, там другая коммуникация, у меня есть статья про общение РП и команды, если вы про это. Там - помощник.
Хитрость метода в статье для меня в том, что нет там уязвимой позиции у меня, как у просящего: я проработал проблему, она есть. Сам я ее решить не могу - почему - написано. Я предлагаю несколько вариантов решения, которые вижу и прошу выбрать.
Не хотите выбирать - предложите свое. Не хотите предлагать - я вас задолбаю этим методом и вы потом не сможете никому сказть, что ваш менеджер вас не предупреждал о проблеме.
Я очень много раз сталкивался с манипуляциями, когда меня, как РП, хотели подставить и сделать крайним. Этот метод выручал реально много раз.
ну если при этом все достигают цели - да. И я не вижу отличия от того, что я написал в статье. Потому что когда менеджер предлагает один из вариантов, он сам решает, какие варианты выбрать. В итоге получается то, что вы и написали.
Предлагаю не переходить на обсуждение качества полушарий собеседника ))
если у вас есть опыт - поделитесь, пожалуйста. Как говорится - "критикуя - предлагай". Почему подход, описанный мной вам в ответе выше неэффективен? какой подход лучше, по вашему опыту?
Я, кстати, сейчас без иронии, мне правда интересно, я допускаю, что многого не знаю. Но у меня действительно большой опыт в моей области, который привел вот именно к таким выводам. Не согласны - поделитесь вашим опытом.
а вот тут не согласен. За руководителя РП думать не должен и не может, у него просто нет столько информации для принятия решения. РП должен решать проблемы в рамках своей компетенции - не правда ли?
Так вот пусть и опишет проблему кратко (это очень полезный навык для РП и при работе с заказчиками, в том числе)
Подумает сам (а не я за него), как он сам может это решить (это крайне полезно, переходить из режима "это невозможно" в режим "мне нужно то-то и то-то, чтобы это сделать")
Распишет решения, кратко, сам оценив их
И знаете что - через 5 таких подходов менеджеры учатся решать проблемы самостоятельно, выходя на новый уровень. И это уже переход РП от middle к senior.
Итог: win-win: и руководителю хорошо и РПшнику тоже.
а всего лишь надо немного подумать перед тем как эскалировать
Ну оценки ставить - дело простое.
Сперва хотел написать про то, что в растущей компании работы всегда больше чем людей (что всегда дает перегруз, зато и рост для всей команды, измеряемый в опыте и деньгах)...
А сейчас думаю, что без разницы какая команда и какая компания. Способ в статье позволяет сотруднику быстро и четко описать проблему - раз. И пока он это упражнение делает, часто он сам решает задачи и идти никуда не надо - два.
То есть у вас двойная польза: и ребята учатся сами решать вопросы без вас, и у вас гораздо больше времени, а уж на что его потратить - решайте сами
Чем плохо и почему азиатчина? :)
да, согласен, это очень тонкая грань, почти неуловимая и индивидуальная для каждой компании и даже для пары РП-руководитель. Очень старался ее хоть как-то отразить и взял максимально трешовые случаи для того, что РП изменить не может.
спасибо, кеп :) А где в вашем определении определение границы ответственности?
Статья как раз про это. А еще про то, что начинающие РП часто не понимают цену своей договоренности. "должен отвечать" - общие слова.
"не получишь зарплату, потому что мне нечем ее платить" - гораздо более понятно.
"подставишь ГД, потому что он уже пообещал срок, который ты дал" - гораздо более понятно.
Но где граница ответственности тогда? РП не боженька всесильный, он не может изменить все, достигая целей проекта - и помнить об этом РП тоже надо, чтобы сильно не загоняться.
я уже ответил коллеге и с удовольствием отвечу еще. Статьи для того и пишу, чтобы обсуждать, вот только хамство считаю недопустимым.
но вообще, статья про другое :)
Отвечу вам по пунктам:
Статья не решает проблему объема/бюджета/рисков. Цель статьи - донести до джунов и тех, кто только еще хочет, понимание того, что РПшникам платят деньги не за то, что они дергают колбаски в Гантте, а совсем за другое. И основное тут для меня - именно ответственность за свои договоренности.
У каждого свой опыт. Вы видели только 2х хороших РП, я видел десятки, из них несколько вырастил лично сам, с нуля. И я знаю, что страшит начинающих РП и знаю проблемы, которыми они грузятся - и большинство моих статей про это.
Про "может изменить" - Я не писал только про риски, неправда ваша :)
про "не может изменить". Я указал там такие случаи:
Расскажите, пожалуйста, ваш опыт про то, что может сделать РП, если проект отменяют без оплаты? Что делать, ваше руководство принуждает РП сделать работы в нереалистичные сроки или не дает команду на это?
К сожалению, в конце просто хамство, вместо конструктива
он никогда не был маленьким. просто в 10х был бум стартапов и кому-то показалось, что команда продуктолог-разработчик отлично решает все-все проблемы любого продукта.
Я даже в популярных ТГ каналах до сих пор слышу апологетов такого подхода. И спорить с ними бесполезно, они просто пока не понимают, что как только продукт начнет расти, понадобится расширять команду и вся эта стройная конструкция опять сведется к так ненавидимому всеми (а зря, кстати) энтерпрайзу
Подумал. Вот 2 основные причины в моем опыте, почему оно не делается:
Заказчик не обладает соответствующими ресурсами для качественного выполнения работ, формирует ТЗ по принципу "как смогла" и выставлет его на тендер. Дальше уже интеграторы "на опыте" смотрят, реалистично сделать то, что в ТЗ или риски слишком велики.
Реактивное управление в компании: решения принимаются внезапно на уровне "ГД сказал сделать" и прдпроектное обследование скатывается в режим "денег заложим, а там что-нибудь придумаем"
В целом, вопрос рисков реализации всем сторонам понятен, потому в стоимость внедрения закладываются дополнительные косты. Судя по тому, что компетенции аналитиков у госзаказчиков (а они - основные заказчики сейчас) не появилось, им дешевле идти путем принятия рисков отсутствия предпроектного обследования