Pull to refresh
4
0

Пользователь

Send message
Мне кажется ваш текст только подчеркивает то, что из правил есть исключения. И этим и отличаются опытные менеджеры, они знают в какой момент правила не работают. Не скажу, что автор статьи на 100% прав, но считаю что правила и догмы нужны, чтобы не придумывать велосипед каждый день заново.
Заметен. Просто нет чисел на руках. Есть пока только постоянное расширения штата разработчиков.
Естественно, что мы следим за тенденциями в статистике количественной и в итоге денежной. Любая статистика должна переводиться в деньги, иначе она теряет смысл для руководства. Контрольные отсечки делаем каждую неделю.
За несколько месяцев мы определили нормальные показатели по всем параметрам. И постоянно улучшаем процессы для увеличения необходимых нам параметров. На все «не здоровые» отклонения мы сразу реагируем и корректируем процессы.
Скорее нужны творцы, отлично понимающие что они творят
В числах мне сложно сказать, наша компания стабильно растет. Но о потерях речь не идет совершенно, мы встраиваем все это в рабочие процессы абсолютнобезболезненно
Согласен, но хотелось бы что бы эти определения входили в обиход в оригинале. В других странах это уже понемногу приживается.
Это легкое введение в терминологию и отсылка к японским корням понятия lean
Я думаю, еще есть смысл всегда в обсуждении требований опираться на договоренности. Клиенты хорошо понимают, если вы говорите, что ТЗ можно трактовать как им нужно, но в диалоге при планировании проекта функционал был очерчен именно так.
Это хороший вариант, о котором никогда не надо забывать. И хорошо, когда клиент приучен к такому. Я имею, в виду, что если ему говорят, что работа не планировалась и он знает, что нужно доплатить.

Но глобально мы говорим о том уровне сервиса, когда все ожидания клиента оправдываются и за счет этого улучшается его фидбэк по проекту. Но в то же время он знает, что это произошло не просто так и с такими недопониманиями при взаимодействии нужно бороться.
Всегда сложно быть в такой ситуации. Я думаю, направления дествий такие:

  1. Попытаться разубедить клиента. Безусловно, если это подходящее решение
  2. Анализ заложенных заранее рисков и применение их на данную фитчу
  3. Поиск компромисса с клиетом. Это как раз «Процесс пересмотра скоупа проекта в условиях изменения функциональности без изменения бюджета» — из статьи

Если есть желание, можем более конкретную ситуацию разобрать в далее комментах или в личных сообщениях

Information

Rating
Does not participate
Location
Омск, Омская обл., Россия
Date of birth
Registered
Activity