Мне кажется, что в этой ситуации дешевле направить усилия на поиск новых клиентов, а не на выправление ситуации с конкретно этим («пожалуйста, а давайте вы не будете нам по ночам писать и криворукими называть», так что ли?).
Потому что при прочих равных плохой клиент всегда обходится дороже, на него уходит больше рабочего времени ваших сотрудников: на коммуникацию, чтобы понять а что вообще нужно, на поплакать под душем, на поиск нового места работы.
Если отказаться от сотрудничества совсем-совсем-совсем никак, то нужно устанавливать четкие правила и приучать клиента. Для клиента такие правила аргументировать пользой: «вы же сами понимаете, что если мы будем брать в работу несформулированную задачу, то потратим больше времени на то, чтобы разобраться, что вообще делать. Поэтому задачи берем в работу только после того, как она выглядит так: 1, 2, 3… Это сэкономит ваши деньги».
Самим эти правила тоже нужно выполнять: если сказать клиенту, что вы не отвечаете на сообщения по ночам, а потом продолжить отвечать, то ничего не получится.
Кстати. Может оказаться, что такой клиент работает с вами как раз потому, что на вас можно наорать и вы все быстро пойдете делать. Поэтому когда появятся какие-то правила, вы ему разонравитесь и он и так уйдет. ¯\_(ツ)_/¯
Суть в том, что в первый раз клиент к нам попал потому что не была налажена жёсткая модерация поступающих лидов. Сейчас такая модерация есть, но для нас этот лид выглядел так, что к нам пришёл уже наш клиент, с которым мы работали. Подумали, что про его «заскоки» мы уже знаем и справимся с ними, но переоценили себя и недооценили клиента.
Мы с вами начали обсуждать фразу про поставновку сроков выполнения задачи — смещать фокус из такого контекста на дистрибуцию до пользователя некорректно, т.к. точные оценки — это одно, а то, что тестирование у вас (видимо) в оценку разработки входит, это другое. Мы следим за утилизацией времени разработчиков (сколько тратится непосредственно на код), и у нас на код тратится ~60% времени (кодревью я сюда же включаю, это тоже работа над кодом). Разработчик — достаточно дорогой ресурс, странно, что вы признаетесь, что на 90% используете его не вцелевую, и вам это ок.
Оценил и ошибся, но сделал в два раза быстрее — разработчик растянет задачу на весь озвученный срок, иначе в следующий раз ему не поверят.
На этом месте загордилась своими коллегами). У нас так не принято. Сделал задачу медленнее — на ретро будем обсуждать, что не учли и как проектировать лучше. Сделал задачу быстрее — берешь следующую, неизрасходованное время потратится на то, чтобы «закрыть» ту задачу, на которой выбились из оценки. Или фиксишь баги. Никто ничего не растягивает.
Даже если ваши разработчики начнут писать код в два раза быстрее, проект закончится раньше только на несколько процентов раньше
Полностью согласна! Только мы обсуждаем не скорость кода, а точность сроков. На оценку разработчика (=планируемое время окончания задачи) подвязывается много процессов, и если разработчик не попадает в оценку, не важно, на 4 часа или 3е суток он опазадал — сроки все равно поедут, т.к. двигаются задачи у QA, других разработчиков и т.д., а у них может вообще под конкретную задачу одно окно было выделено, а потом — другой проект. Моя задача, как менеджера — не чтобы все было максимально быстро (хотя да), а чтобы несколько людей работали слажено и минимально тормозили друг-друга съездами по срокам.
Не согласна с вами, что в проектном менеджменте нет времени на процессы, и поэтому срочно стоит идти в продуктовый — вы же не внедряете под каждый проект процессы с 0, одни и те же процессы работают на всех проектах и могут оптимизироваться несколькими менеджерами, главное правильно настройте метрики. Фокусироваться надо не на каких-то странных «проектных / продуктовых» процессах, а на процессах в бизнесе.
В ситуации «выиграли тендер» действительно не оказывались, потому что сознательно их избегаем (и вы тоже можете начать).
В ситуации «сэйлзы так продали» и я, и мои коллеги оказываемся систематически: банально, продали решение, которое оказалось неподходящим (а подходящее стоит дороже). И я считаю, что эта ситуация на 100% зависит от менеджера — моя задача договориться с клиентом и при этом оставить его лояльным. Если у вас сейлз всегда продает в убыток, а менеджеры не могут договариваться, то… не оч у вас все.
В чем состоит проблема, как вам кажется? Пока действительно не улавливаю причину вашего недовольства, раз мы начали обмениваться мнениями, то давайте обсуждать не только то, в чем я (по вашему мнению) неправа но и то, как сделать оптимальнее. Мы гибкие в плане процессов ребята, и если почерпнем что-то полезное из комментов на Хабре, то нам будет не стремно это внедрять).
Что касается ответов на вопрос: да, на некоторых проектах оценивает только один человек — обязательно тот, кто будет выполнять задачу. Проекты раньше календарного срока почти не завершаются, но это не только из-за коэффициентов, кроме этого стараемся делить работу на маленькие итерации, так проще прогнозировать.
Если не вырывать фразу из контекста, то было написано:
Переоценивать свои силы склонны некоторые джуниоры и мидлы. С опытом хороший менеджер начинает это понимать и вносит коррективы: например, услышав оценку в 10 часов, он умножает её на 2 и получает результат, впоследствии оказывающийся более верным.
Что из этой фразы кажется жестью?
Конечно, здесь речь не идет о буквальном умножении на 2 всех сроков: например, у нас в компании для защиты от риска, когда разработчик некорректно оценил, используется система коэффициентов (от 0,5 до 1, где единица — сеньор). Все сроки делим на этот коэфициент. Важно понимать, что такая схема используется для определения только кадендарного срока проекта: когда считаем бюджет, берем «голую» оценку разработчика. Таким образом, клиент платит за фактическое выполнение задачи, а не за то, что работу выполняет джун или мидл вместо сеньора.
что делать с нереальными дедлайнами и в ситуации, когда доп.ресурсов не получить и скоуп работ не уменьшит
Этот вопрос надо задавать по-другому: а откуда такой нереальный дедлайн вообще взялся? Ну и многое зависит от того, кто вы в команде.
Если вы менеджер, то это как раз ваша работа — договориться, чтобы дедлайн был реальным.
Если вы программист, то влияйте на дедлайн: просите больше времени на проектирование, разбирайте задачу по кусочкам и давайте более точную оценку выполнения, чтобы задница потом не горела.
На моей практике была только одна ситуация, когда у разработчика всегда были нереальные дедлайны: когда мы пилили продукт, разработчик не проектировал и называл сроки задач интуитивно, а когда сроки проходили, говорил: «нууууу… там сложности, ктож знал». При этом когда я спрашивала, а почему сложности не выяснились на берегу, мне говорили «Ну ты же про сроки спрашивала и НАДО БЫЛО БЫСТРЕЕ, а на оценку надо еще времени». Это был косяк обоих, и мой (как менеджера), и разработчика.
Мой — в том, что я не донесла до разработчика приоритеты и не объяснила, что точность важнее скорости. Разработчика — в том, что он брал задачи без декомпозиции и проектирования и не сказал «Э, погодите, это вне здравого смысла. Я так не работаю.»
Потому что при прочих равных плохой клиент всегда обходится дороже, на него уходит больше рабочего времени ваших сотрудников: на коммуникацию, чтобы понять а что вообще нужно, на поплакать под душем, на поиск нового места работы.
Если отказаться от сотрудничества совсем-совсем-совсем никак, то нужно устанавливать четкие правила и приучать клиента. Для клиента такие правила аргументировать пользой: «вы же сами понимаете, что если мы будем брать в работу несформулированную задачу, то потратим больше времени на то, чтобы разобраться, что вообще делать. Поэтому задачи берем в работу только после того, как она выглядит так: 1, 2, 3… Это сэкономит ваши деньги».
Самим эти правила тоже нужно выполнять: если сказать клиенту, что вы не отвечаете на сообщения по ночам, а потом продолжить отвечать, то ничего не получится.
Кстати. Может оказаться, что такой клиент работает с вами как раз потому, что на вас можно наорать и вы все быстро пойдете делать. Поэтому когда появятся какие-то правила, вы ему разонравитесь и он и так уйдет. ¯\_(ツ)_/¯
Суть в том, что в первый раз клиент к нам попал потому что не была налажена жёсткая модерация поступающих лидов. Сейчас такая модерация есть, но для нас этот лид выглядел так, что к нам пришёл уже наш клиент, с которым мы работали. Подумали, что про его «заскоки» мы уже знаем и справимся с ними, но переоценили себя и недооценили клиента.
На этом месте загордилась своими коллегами). У нас так не принято. Сделал задачу медленнее — на ретро будем обсуждать, что не учли и как проектировать лучше. Сделал задачу быстрее — берешь следующую, неизрасходованное время потратится на то, чтобы «закрыть» ту задачу, на которой выбились из оценки. Или фиксишь баги. Никто ничего не растягивает.
Полностью согласна! Только мы обсуждаем не скорость кода, а точность сроков. На оценку разработчика (=планируемое время окончания задачи) подвязывается много процессов, и если разработчик не попадает в оценку, не важно, на 4 часа или 3е суток он опазадал — сроки все равно поедут, т.к. двигаются задачи у QA, других разработчиков и т.д., а у них может вообще под конкретную задачу одно окно было выделено, а потом — другой проект. Моя задача, как менеджера — не чтобы все было максимально быстро (хотя да), а чтобы несколько людей работали слажено и минимально тормозили друг-друга съездами по срокам.
Не согласна с вами, что в проектном менеджменте нет времени на процессы, и поэтому срочно стоит идти в продуктовый — вы же не внедряете под каждый проект процессы с 0, одни и те же процессы работают на всех проектах и могут оптимизироваться несколькими менеджерами, главное правильно настройте метрики. Фокусироваться надо не на каких-то странных «проектных / продуктовых» процессах, а на процессах в бизнесе.
В ситуации «сэйлзы так продали» и я, и мои коллеги оказываемся систематически: банально, продали решение, которое оказалось неподходящим (а подходящее стоит дороже). И я считаю, что эта ситуация на 100% зависит от менеджера — моя задача договориться с клиентом и при этом оставить его лояльным. Если у вас сейлз всегда продает в убыток, а менеджеры не могут договариваться, то… не оч у вас все.
В чем состоит проблема, как вам кажется? Пока действительно не улавливаю причину вашего недовольства, раз мы начали обмениваться мнениями, то давайте обсуждать не только то, в чем я (по вашему мнению) неправа но и то, как сделать оптимальнее. Мы гибкие в плане процессов ребята, и если почерпнем что-то полезное из комментов на Хабре, то нам будет не стремно это внедрять).
Что касается ответов на вопрос: да, на некоторых проектах оценивает только один человек — обязательно тот, кто будет выполнять задачу. Проекты раньше календарного срока почти не завершаются, но это не только из-за коэффициентов, кроме этого стараемся делить работу на маленькие итерации, так проще прогнозировать.
Что из этой фразы кажется жестью?
Конечно, здесь речь не идет о буквальном умножении на 2 всех сроков: например, у нас в компании для защиты от риска, когда разработчик некорректно оценил, используется система коэффициентов (от 0,5 до 1, где единица — сеньор). Все сроки делим на этот коэфициент. Важно понимать, что такая схема используется для определения только кадендарного срока проекта: когда считаем бюджет, берем «голую» оценку разработчика. Таким образом, клиент платит за фактическое выполнение задачи, а не за то, что работу выполняет джун или мидл вместо сеньора.
Этот вопрос надо задавать по-другому: а откуда такой нереальный дедлайн вообще взялся? Ну и многое зависит от того, кто вы в команде.
Если вы менеджер, то это как раз ваша работа — договориться, чтобы дедлайн был реальным.
Если вы программист, то влияйте на дедлайн: просите больше времени на проектирование, разбирайте задачу по кусочкам и давайте более точную оценку выполнения, чтобы задница потом не горела.
На моей практике была только одна ситуация, когда у разработчика всегда были нереальные дедлайны: когда мы пилили продукт, разработчик не проектировал и называл сроки задач интуитивно, а когда сроки проходили, говорил: «нууууу… там сложности, ктож знал». При этом когда я спрашивала, а почему сложности не выяснились на берегу, мне говорили «Ну ты же про сроки спрашивала и НАДО БЫЛО БЫСТРЕЕ, а на оценку надо еще времени». Это был косяк обоих, и мой (как менеджера), и разработчика.
Мой — в том, что я не донесла до разработчика приоритеты и не объяснила, что точность важнее скорости. Разработчика — в том, что он брал задачи без декомпозиции и проектирования и не сказал «Э, погодите, это вне здравого смысла. Я так не работаю.»