“Bad behavior should be discouraged but not banned” – one of the core principles of Python.
Previously on Evercode Lab Advent
…находить выход из любых ситуаций, сохранять кожу упругой, а волосы мягкими и шелковистыми.
Бизнес без факапов — это миф…
…настойчиво рассказываем друг другу о том, что у нас «болит»
Допустим, всё плохо
Я уже писал про наши замечательные факапы, но сегодня хочется посмотреть на вопрос немного шире. Идея составить что-то типа FAQ для типичных некомфортных ситуаций крутилась у меня в голове очень давно. В этом году я нашел замечательный пример того, что хотел составить сам, на сайте компании «Собака Павлова» под названием «Схема эскалации проблем на проекте». А сегодня попробую сделать похожее, но в адаптации под наши реалии.
На проекте обнаружился баг
Проект запущен, клиент счастлив, толпа ликует. Проходит неделя и клиент сообщает, что некоторые пользователи не могут сделать важное. Говорят, ошибка.
Мы, конечно, поможем разобраться и устранить проблему как можно быстрее.
Клиент недоволен конечным результатом
Мы в двух шагах от запуска проекта, прошли вместе с клиентом уже с десяток недельных итераций. На соответствующем количестве встреч его устраивали промежуточные результаты. Но сейчас вдруг все не нравится. Это не так должно работать, тут я хотел на самом деле по-другому.
Если в проекте есть баги и ошибки, которые мы сами не заметили вовремя, то мы обязуемся их исправить. Но бывает, что клиент просто пытается отсрочить запуск или найти изъян. Причины могут быть разными. Мы постараемся убедить, что в большинстве ситуаций запущенный проект, пусть и не идеальный во всех отношениях, все-таки лучше никому неизвестного. Если проект уже может быть показан своим первым пользователям, Клиент может начать собирать какие-то реальные данные по тому, что действительно не так и не то.
Клиент отказывается признавать процесс работы над проектом
Мы все такие четкие, пришли к клиенту и говорим: вот пользуйся этой штучкой, чтобы нам написать про то, этой штучкой, чтобы про это. А ему так неудобно.
Это нормально. И если клиенту удобнее по телефону или лично, то ничего страшного в этом нет. Сами задокументируем для себя и истории.
Но если не хочется признавать необходимость регулярных встреч, уточнений, вопросов, сверок-проверок, тут вопрос другой. Инструменты вторичны, а коммуникации очень важны. В этой ситуации велика вероятность возникновения недопонимания на этапе сдачи проекта. Мы строим работу над проектами так, чтобы максимально эффективно и комфортно для всех сторон получить требуемый результат. Поэтому хаос тут недопустим.
Требования к проекту постоянно меняются
Вчера клиент хотел спасательную шлюпку, сегодня уже крейсер. Ну и что, что все по-другому, и результаты за неделю выкидывать. Смотрите, как у вас шлюпка быстро прорисовалась, крейсер же не сложнее.
Если такое случается один раз, то мы можем оценить новый крейсер и взяться его делать. Конечно, постараемся все-таки обсудить, действительно сразу нужен крейсер? Может, выгоднее будет сначала хотя бы лодку на воду спустить.
Если перемены регулярны и непредсказуемы, то предстоит серьезный разговор с клиентом с попыткой узнать, понимает ли он сам, что хочет создать в итоге. Нам работать в стол хоть иногда и приходится, но совсем не интересно.
Сроки навязываются клиентом
Мы делаем оценки, планируем работу, показываем клиенту. А ему надо в три раза быстрее. Почему? Ну, хочется так. Или другие ребята говорили, что будет быстрее.
Бывает, что у клиента важная выставка, встреча, демонстрация. Тогда спешку можно понять. Такие вещи надо обсуждать заранее и искать приемлемый для всех способ сделать нужное именно для этого события. Хочется показать потенциальным пользователям систему — давайте сделаем минимальную демку.
Иногда можно для ускорение подключить к проекту больше людей. Но ускорение с увеличением количества разработчиков, к сожалению, нелинейное. А стоимость выше.
А если объективных причин для стрессовых условий по срокам нет, то мы предпочтем настоять на приемлемом режиме работы. Так и качество будет намного лучше.
Мы неправильно поняли клиента
Клиент вдохновлено объясняет, размахивает руками, что-то рисует. Но мы его не понимаем. Не идет и всё.
Если проблема в знании предметной области, то постараемся изучить. Иногда клиенту не хватает системности, тогда будем задавать вопросы и вести его последовательно к ясной картине.
Если ничего не помогает, то честно признаемся, что не смогли.
Мы не успели в срок
Даже с подходом fixed price, fixed time, flexible scope бывают сбои. У нас кто-то заболел. Мы думали, что будет легко, а оказалось совсем не так. Ошиблись с приоритетами, заигрались технологиями, с кем не бывает.
Как правило, мы всегда понимаем, когда сами виноваты в таких случаях. И мы компенсируем просрочки за свой счет.
Но бывает, что нам о чем-то не сказали, мы этого сами ну никак предполагать не могли, даже подумать. А оно взяло и всплыло. Тогда будем обсуждать и договариваться.
Мы про что-то забыли
Клиент просил, писал, сказал, упомянул. Мы старались, конспектировали, заносили. Но вот что-то упустили, проглядели.
Такое редко, но случается. Промах признаем, забытому внимание уделим.
Клиент подразумевал
Клиент описал задачу. Мы декомпозировали, описали подробнее, показали-рассказали ему еще раз, что хотим сделать. Он согласился. Мы сделали. А он подразумевал, что будет сделано еще и другое.
Такое недопонимание случается. Иногда клиент ассоциирует один функционал с другим на основе того, что видел ранее. А мы так не сделали, поэтому результат с ожиданием разошелся.
Если это что-то небольшое, то вероятнее всего мы просто возьмем и добавим. Если долгое и нетривиальное, то обсудим и запланируем на ближайший этап работ.
Клиент не доволен командой проекта
Договорились мы с клиентом, выделили ему команду на проект, закипела работа. Проходит неделя-две, и он сообщает, что не нравятся ему эти люди. Говорят странно, одеваются непонятно, делают неизвестно что.
Пытаемся разобраться. Бывает, что люди просто не сходятся, не находят общего языка, характеры прямо совсем разные. Но это очень редко.
Если кто-то из нас действительно повел себя неправильно, извинимся, проведем воспитательные работы. Клиенту предложим попробовать еще, но уже немного по-другому. Будем присматривать. Если не хочет пробовать с теми же, попробуем организовать замену. Если ситуация повторится, то пройдем круг еще раз, но уже задумаемся, в нас ли дело.
Клиент задерживает оплату
Выполнили работы, согласовали результат, радостные ждем оплату. А ее все нет и нет.
Мы работаем по Заданиям, которые являются приложениями к договору. Каждое задание редко превышает по продолжительности месяц. Так мы снижаем свои риски, а клиенту предоставляем пошаговый результат. Соответственно после каждого такого этапа мы подписываем акт и выставляем счет на согласованную сумму за вычетом аванса. Иногда график платежей не соответствует этой схеме, тогда он обсуждается и фиксируется с клиентом заранее.
Если оплата задерживается, то мы постараемся узнать и понять причины. Когда у клиента проблемы, поймем и даже немного подождем. Если почувствуем, что дальше так не можем, то текущие работы прекратим. Договориться и найти приемлемое решение сложившей ситуации попробуем всегда. Истерить не будем, говорить будем вежливо, но настойчиво.
Клиент не согласовывает документы
Выполнили работы, клиент доволен, проект запущен. А подписывать акты отказывается.
Как правило, такого не бывает. Клиент отказывается подписывать акт, когда он чем-то недоволен. Значит, надо понять, чем именно. И потом вместе решить, как эту ситуацию изменить к лучшему.
Клиент супер, и мы отличные ребята
And they lived happily ever after… oh, wait!
Эта статья является частью Evercode Lab Advent 2014 — цикла из 24 статей о том, как появилась, устроена и работает компания Evercode Lab. Полный список статей можно посмотреть в анонсе Evercode Lab Advent.
