«Да, да, приобщиться к цивилизации – дело весьма нелегкое. Для этого есть два пути: культура или так называемый разврат.» — Оскар Уайльд, «Портрет Дориана Грея»
Previously on Evercode Lab Advent
…и факапы разной степени эпичности.
Допустим, все прекрасно.
Fail early, fail often. Unless someone dies.
Ошибаются все. No exceptions. Бизнес без факапов — это миф, ведь бизнес делают люди. В нашей сфере и при наших размерах масштабы совершённых ошибок могут быть разными. Конечно, когда делаешь веб-проекты, то редко от твоих действий зависит жизнь человека или судьбы миллионов. Потенциально это возможно, но на практике встречается не так и часто.
Мы сами совершили порядочное число ошибок, которые приводили к неприятным и напряженным ситуациям, недовольству клиентов, иногда отказу от них, нашему недовольству и нашим убыткам тоже. По глупости, неопытности, незнанию, опять по глупости. Вечер пятницы отличное время, чтобы вспомнить о некоторых из них.
Вот список того, в чем мы ошибались:
- оценка сроков на проект и задачи
- приоритезация выполнения задач
- контроль субподрядчиков (по дизайну и верстке)
- построение коммуникаций с клиентом
- коммуникации внутри команды
- построение процесса разработки в целом
- небрежное отношение к документам
- рентабельность работы над конкретным проектом
Список я могу продолжать довольно долго. Но лучше расскажу несколько историй.
Куда вы спешите
На одном из первых наших проектов, портале информационных технологий, оптики и фотоники для ИТМО, мы попали в условия сжатых сроков. Нас попросили помочь с программной частью как субподрядчиков. Срок с клиентом уже был зафиксирован, бюджет тоже, и даже ТЗ.
Естественно, мы сразу сказали, что срок нереальный. У ребят даже дизайн еще не был готов и согласован. Нас попросили сделать все, что в наших силах. Мы согласились. В результате это вылилось для нас в приличное время переработки, спешку, несколько разговоров с исполнителем по дизайну на повышенных тонах, сильный минус по деньгам.
В конечном итоге с ситуацией мы справились, с представителем заказчика стали работать напрямую, больше разговаривать, объяснять, строить процесс. Проект запустили, продолжили работу на поддержке, на которой частично все-таки компенсировали минус по деньгам.
Почему вы об этом нам не сказали
Следущий крупный фейл был с разработкой системы приема-принятия объявлений для онлайн и бумажного издания. Заказчик находился на дальнем востоке России. Заказ к нам перешел от другого программиста.
Главная ошибка состояла в том, что посмотрев задание и сопоставив его с бюджетом, мы не уделили времени обсуждению и уточнению деталей. В дополнение к этому все общение мы вели исключительно письменно, голосом не общались ни разу, попытки договориться с клиентом на созвоны по скайпу систематично проваливались.
Мы были уверены, что все хорошо, реализовали функционал, готовились к запуску. В результате только перед самим запуском на нас посыпались новости. Оказалось, что нам не рассказали про сложности и особенности системы, которую наша должна заменить. Из старой системы нужно было импортировать данные, которые хранились разрозненно в нескольких местах. В дополнение к этому, алгоритмы подсчета цен на объявления тоже оказались гораздо сложнее, чем было описано изначально.
Все это вылилось в пару недель работы по ночам из-за разницы во времени, претензии от нас к заказчику, от заказчика к нам. К сожалению, донести нашу позицию мы не смогли, снизить градус общения тоже. После логического завершения этапа работ от продолжения мы отказались.
Мы это подразумевали
С проектом Picademy, запущенным в этом году, мы в последний раз осознали тщетность попыток работать «по ТЗ». Несмотря на то, что мы неоднократно проговаривали, что работаем этапами по задачам, которые регулярно обсуждаем и уточняемо, наличие начального ТЗ нам аукнулось. На какое-то время фраза «мы это подразумевали» стала для нас локальным мемом именно из-за этого клиента.
Конечно, тут нет вины клиента. Наша ошибка состояла в том, как мы доносили до ребят информацию, как описывали, какой будет конечный результат тех или иных работ.
К счастью, во всех ситуациях мы в итоге приходили к компромиссу. Запущенным проектом мы очень гордимся. С заказчиком мы после полугода поддержки все-таки расстались, но совсем по другим причинам и, сохранив хорошие отношения.
Куда все пропало
Бывали у нас, конечно, и технические факапы. Самый недавний из них — потеря данных в продакшн базе клиента накануне запуска их мобильного приложения. Из-за ошибки в коде при определенных действиях в админке происходило плохое, и работа контент-отдела клиента за три недели в один момент пропала.
Конечно, мы отработали эту ситуацию. Ошибка была исправлена, причины ее появления выявлены. Данные по максимуму, хоть и не все, восстановлены из бэкапов. Потери мы компенсировали соразмерной работой за свой счет. Клиент не только не выразил желания прекратить с нами работать, но и просил добавить на проект разработчиков.
Не ошибается тот, кто ничего не делает
Я не вижу смысла скрывать наши факапы. Все эти истории — уроки для нас. Проблемы надо не замалчивать, а использовать как шанс что-то изменить в лучшую сторону. Каждый раз стоит сделать выводы. Понять, как перестроить процессы, как изменить отношение, как объяснять и доносить. В конце концов, осознать, что не все клиенты подходят нам, и мы подходим не всем клиентам.
Самое сложное в подобных ситуациях — это эмоции. Когда что-то идет не так, люди злятся, нервничают, грустят. Выражается это по-разному. Переносить самому это часто тоже не просто. Наши первые ошибки иногда сильно выбивали лично меня из колеи. Постепенно пришло понимание того, как с этим работать. Как и умение отделять себя от своей работы. Концентрироваться на правильных вещах, не впадая в уныние. И продолжать двигаться дальше.
“Success consists of going from failure to failure without loss of enthusiasm.” – Winston Churchill
Эта статья является частью Evercode Lab Advent 2014 — цикла из 24 статей о том, как появилась, устроена и работает компания Evercode Lab. Полный список статей можно посмотреть в анонсе Evercode Lab Advent.