Как стать автором
Обновить

Комментарии 13

А не будет ли возможности скачать вебинар по окончанию? Иногда хочется освежить информацию в голове, но неоткуда. Заморачиваться со скринингом не хочется.
Запись вебинара постараемся сделать, если ничего не сбойнет. Не обещаем выложить быстро (надо будет редактуру навести), но будем стараться. :)
Не особо понятно, откуда тут «8. Разговор с новыми коллегами» появился. То есть, если рассматривать типичную компанию, в которой у каждой команды есть свой проект со своим менеджером, то какая необходимость у этого менеджера целенаправленно общаться со своими коллегами. Просто другие разговоры действительно в моей голове хорошо укладываются, они логичны, а этот разговор — что-то в стороне.

P.S. Я теоретик, практики нет такой.
Спасибо за вопрос. Тут надо смотреть на организационную структуру компании. Насколько команды автономны или же наоборот увязаны в более крупный проект.

Например, в том же Intel были как автономные команды из 3-5 человек, так и большие проекты на 150 человек, состоящие из 20 команд. И там менеджерам приходилось довольно плотно работать.

Но даже в случае автономных команд остаются вопросы перераспределения людей между командами — то есть. найдется о чем поговорить. :)
Понятно, спасибо за ответ.
Спасибо за цикл статей :)

5. Какие были договоренности с предыдущим менеджером

Подскажите, пожалуйста, какова статистика по успешности использования этого вопроса:
  1. Удивлялся ли клиент, почему у такой серьезной компании/менеджера возник такой вопрос и не потеряны ли все материалы проекта?
  2. Пытался ли клиент назвать договоренности, которых на самом деле не было и если да, то как быть, чтобы сохранить рабочие отношения и прибыль?
  3. Как минимизировать потери и, желательно, получить дополнительные преимущества, если предыдущим менеджером были достигнуты невыполнимые договоренности?
  4. Имеет ли смысл заново обсудить проектную документацию, чтобы убедиться, что она актуальна, а не стала результатом следования формальностям?

Думаю, тут могут быть и другие вопросы, о которых я сейчас не вспомнил.
Удивлялся ли клиент, почему у такой серьезной компании/менеджера возник такой вопрос и не потеряны ли все материалы проекта?

Очевидно, не все договоренности фиксируются в документах, именно их и нужно прояснить

Пытался ли клиент назвать договоренности, которых на самом деле не было

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

Удивлялся ли клиент, почему у такой серьезной компании/менеджера возник такой вопрос и не потеряны ли все материалы проекта?


Имхо зависит от того, как спросить. Я бы начал в стиле: «Поскольку я менеджер новый, то могу всех деталей не знать. Чтобы проверить, что я знаю про все договоренности...».

Однажды на семинаре мне задали вопрос: «Какие вопросы нельзя задавать заказчику?» У меня реально вскипел мозг, потому что я никогда не думал в этом направлении. :) В итоге я пришел к следующей мысли. Можно задавать те вопросы, про которые вы можете адекватно объяснить, зачем вы их спрашиваете.

Пытался ли клиент назвать договоренности, которых на самом деле не было и если да, то как быть, чтобы сохранить рабочие отношения и прибыль?


Не сталкивался с таким поведением. Я бы брал паузу: «Прошу прощения, был не в курсе этой договоренности. Поговорю еще раз с Колей, что у нас по этому поводу есть.» — мало ли предыдущий менеджер забыл рассказать об этой договоренности. Потом бы возвращался со словами: «Эта договоренность не была включена в план. Если это актуально, давайте думать, что делать дальше.»

Как минимизировать потери и, желательно, получить дополнительные преимущества, если предыдущим менеджером были достигнуты невыполнимые договоренности?


Тут имхо, как можно быстрее после того, как это стало понятно, идти бы к руководителю советоваться. При этом имея на руках факты, подтверждающие ваши слова про нереальность договоренностей. И дальше с руководителем решать, что делать. Варианты всегда есть:
  • Сверхурочная работа
  • Подтянуть людей из соседних команд
  • Пересмотреть объем работ заказчиком
  • Перенести сроки
  • ...


Поскольку в этой ситуации нет вашей вины, то главная задача здесь — принести факты, которые бы четко показали, что проблема есть и насколько велик размер этой напасти. :)

Имеет ли смысл заново обсудить проектную документацию, чтобы убедиться, что она актуальна, а не стала результатом следования формальностям?


Если заказчика она устраивает, то я бы на первом этапе не обсуждал. Во время последующих встреч можно проверить, насколько ее хватает, чтобы у заказчика была прозрачность по поводу вашей деятельности. На первой встрече я бы спросил, хочет ли он что-то поменять в плане коммуникаций. Очень может оказаться, что он захочет, например, общаться чаще. (Менеджер все-таки новый, бог его знает, как там что пойдет. :))

Какие-то такие мысли.
Во-первых, eagleson, FiresShadow, спасибо за развернутые ответы.
Во-вторых,
Поскольку в этой ситуации нет вашей вины

Обычно со мной не бывает такого, что чужую вину пытаются записать на мой счет :) Свою, конечно, признаю сразу, как только понимаю ее наличие.
Меня скорее интересует, как от лица компании так сделать, чтобы и не проиграть, и получить выгодну (хотя бы даже в виде лояльности или понимания и уверенности со стороны клиента, что «вот эти ребята адекватные, с ними не страшно оказаться в сложной ситуации»)?

P. S.
Можно задавать те вопросы, про которые вы можете адекватно объяснить, зачем вы их спрашиваете.

Чтобы предусмотреть многие «тонкие» моменты будущих проектов или крупных доработок заранее, часто ходил в этом смысле по грани. Приходилось объяснять, зачем спрашиваю, как только чувствовал некие немые вопросы на лицах клиентов :)
уверенности со стороны клиента, что «вот эти ребята адекватные»

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

с ними не страшно оказаться в сложной ситуации

Как мне кажется, в сложной ситуации важно понимать ситуацию и главное — уметь прогнозировать её. Эти навыки позволят принять правильное решение; а если заказчик понимает, что вы обладаете этими навыками, то это вселит в заказчика уверенность. Если же ситуация не до конца ясна, то открытые и прозрачные отношения с заказчиком и командой помогут восполнить пробелы в понимании. Также нужно понимать основную причину недовольства заказчика — потеря прибыли (в том числе потенциальной, так называемая упущенная выгода). Но потеря прибыли может быть и не по вине IT-команды, например если сложности вызваны непониманием рынка => реализацией не тех фич => неокупаемостью, и тогда понимания ситуации управленцем IT-команды (в данном случае ситуации на рынке) может оказаться недостаточно и тут нужно опрашивать конечных потребителей, привлекать маркетологов, анализировать рынок и пр. А для управленца на первый план в такой ситуации часто выходит способность мотивировать людей на сверхурочную работу (чтобы в срочном порядке переделывать продукт)…
Очередная статья-приманка. Каждый раз читаю и жду: ну, вот в этой уже наконец-то раскроют тему до конца. Ан нет, и тут — вебинар.
На статью про встречи 1:1 непонятно, когда соберемся. Но запись вебинара есть — там как раз постарались тему до конца раскрыть:

Видео: https://vimeo.com/113628621
Слайды: pptx, pdf

Продолжительность: 1 ч. 52 мин.
В любом случае вы, парни, молодцы =) Очень интересно и полезно пишете.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий