Практически каждый опытный разработчик может рассказать не одну историю о том, как перспективный поначалу проект, так и не завершился релизом. В некоторых случаях причиной «заморозки» становятся финансовые сложности и форс-мажоры. Но намного чаще основная проблема – отсутствие взаимопонимания с заказчиком. Реализация затягивается, появляется множество претензий друг к другу, заказчик требует постоянных доработок и переделок. В итоге, программный продукт так и остается незавершенным либо оплаченные программные решения остаются «пылиться в коробках».
Ошибки при взаимодействии с заказчиками допускают как разработчики программных продуктов «с нуля», так и специалисты по внедрению. Давайте вместе разберемся, какие ошибки допускают чаще всего, и как их избегать.
1. Никогда не работайте без технического задания
Эта ошибка настолько популярна, что именно с нее мы и решили начать. Заказчики очень часто не хотят заполнять подробные брифы, не говоря уже о составлении технического задания, вместо этого предлагают встретиться или обсудить задачу голосом по телефону или через скайп.
Возможные результаты такого подхода:
- Оговариваются только основные вопросы, все особенности реализации разработчик выполняет так, как считает нужным. Но заказчик ждал совсем другого.
- Отсутствие плана и документально зафиксированных сроков выполнения работ позволяют программисту работать в удобном для себя режиме. Нередко при этом сроки затягиваются, что приводит к недовольству со стороны заказчика.
- Проект выполняется, в процессе работы заказчик одобряет решения программиста. Но на финальной стадии оказывается, что он хотел не совсем такой результат или подразумевал больший объем работ за те же деньги.
Могут быть и другие сложности. Но все они приводят к печальному итогу. Либо разработчик ради сохранения хорошей репутации вынужден выполнять все пожелания заказчика, при этом теряет время и, как следствие, деньги. Либо возникает конфликт и стороны расходятся без завершения проекта, крайне недовольные друг другом.
Избежать такой ситуации очень просто. Никогда не начинайте работу без четко составленного и утвержденного технического задания.
Чаще всего последовательность действий такая:
- На переговорах заказчик с программистом или менеджером компании разработчика обсуждают все основные вопросы.
- Заказчик заполняет подробный бриф.
- На основе брифа силами разработчиков составляется техническое задание.
- Документ согласовывается с заказчиком и становится неотъемлемой частью договора.
В отдельных случаях можно вместо брифа провести подробное обсуждение при помощи голосовой и видеосвязи. При этом разговор в обязательном порядке записывается. И уже на его основе составляется техническое задание. Если заказчик отказывается подробно обсуждать все нюансы проекта, заполнять брифы и работать с ТЗ, лучше сразу отказаться от сотрудничества. Это явный признак будущих проблем.
2. Неверная оценка сроков
Опытным программистам известна аксиома: любой проект длится дольше, чем запланировано, и всегда завершается после дедлайна. Но при этом заказчик ориентируется на составленное разработчиками техзадание, которое содержит в числе прочего план основных этапов работы с календарным графиком. Само собой, что это – распространенная причина конфликтов, а нередко даже основание для снижения суммы оплаты.
Как избежать проблем:
- Адекватно оценивайте сроки. Если нет опыта и уверенности, посоветуйтесь с коллегами. А потом добавьте к этому сроку еще немного времени. Просто «про запас».
- Всегда указывайте, что в случае проволочек со стороны заказчика, например, при утверждении прототипа или предоставлении важной для реализации информации, срок увеличивается на время, потерянное по вине заказчика.
- Если заказчик просит дополнить проект дополнительными функциями, обязательно оповестите его, что реализация затянется на дополнительный срок, необходимый для написания неучтенного заранее функционала. Кстати, не забудьте, что также и сумма оплаты соответственно возрастает. В идеале, такие «хотелки» оформляются отдельными договорами или дополнительными соглашениями.
- Если проблема со сроками возникла по вине разработчика, поставьте в известность заказчика как можно раньше. Все мы живые люди, а потому иногда болеем, решаем какие-то срочные проблемы. Да и в процессе работы иногда появляются баги, которые приходится «ловить» не один день. Если вы по-человечески предупредите о переносе сроков, скорей всего, заказчик отнесется к этому с пониманием. Конечно, если вы не будете этим злоупотреблять.
- Не перегружайте заказчика подробностями и никогда не лгите. Этот пункт служит неким дополнением предыдущего. У вас сложный баг и нужно затянуть проект на 3 дня? Нет никакого смысла рассказывать о технических нюансах. Просто сообщите, что появились некоторые технические сложности, которые вы не предвидели на этапе планирования. Проект затянулся из-за внезапной простуды ведущего специалиста? Об этом тоже можно кратко сообщить. Но если у вас будет постоянно «пропадать интернет», «болеть бабушка» или понадобится «похоронить любимого хомячка», вас не станут ловить на лжи. Но доверие к вам, как к профессионалу и деловому партнеру, будет подорвано.
Иногда заказчик принципиально снижает сумму оплаты в случае «просрочки». Штрафные санкции должны быть прописаны в договоре. Подписали? Придется соглашаться. При сотрудничестве с подобными людьми лучше заранее увеличить время выполнения каждого этапа в техническом задании. А если вдруг сумеете выполнить раньше, будет только плюс. Правда, практика показывает, что раньше времени программы не пишутся. Независимо от «раздувания» срока.
3. Договор или работа «на доверии»
Официальный договор о сотрудничестве, где прописаны все условия и суммы, станет лучшим решением для защиты интересов, как программистов, так и заказчиков. Но все мы знаем, что заключают его далеко не всегда. Чаще всего отказ от договора диктуется банальным желанием избежать уплаты налогов. Но при этом важно помнить, что такие отношения чреваты большими проблемами.
При работе «на доверии» заказчик может отказаться оплачивать работу или потребовать дополнительные услуги в рамках проекта. В случае предоплаты появляется риск для другой стороны. Проект может быть выполнен не качественно или не выполнен вообще.
Фрилансеры-одиночки соглашаются на эти риски, так как они почти всегда выполняют небольшие объемы работ и, соответственно, рискуют небольшими суммами. Но если вы беретесь за внедрение крупной информационной системы или создаете программный продукт «с нуля», сотрудничество предстоит длительное, и кто знает, не изменятся ли настроения заказчика через 2-3 месяца? Здесь без договора работать просто недопустимо.
Кстати, во многих странах, в том числе в России, неуплата налогов может окончиться крупными штрафами и блокировкой счетов. Стоит ли того «экономия»?
4. Работа «по-приятельски»
Эта проблема широко известна во всех сферах бизнеса. О том, насколько вредны в бизнесе родственники и друзья, написаны миллионы статей с примерами и печальными выводами. Люди – всегда люди. И как только вы смешиваете личные отношения и бизнес-интересы, начинаются просьбы о скидках или бесплатных услугах «по дружбе». Исполнители начинают работать «спустя рукава», ведь вы – свой, а потому все равно простите и т.д.
Существует «золотое» правило: бизнес и личные отношения – отдельно. Если ваши знакомые не понимают, что никаких преимуществ «по дружбе» не будет, лучше откажите им сразу. Иначе вы либо потеряете друзей, либо будете постоянно работать себе в убыток.
Но здесь есть еще один важный нюанс. Некоторые заказчики в процессе работы пытаются с подружиться с исполнителем. Вместо делового разговора начинаются обсуждения «вчерашнего футбола», погоды, семейных проблем. И если вы позволите им «перейти черту» делового общения, в итоге получите тех самых «приятелей в бизнесе». Рано или поздно появятся просьбы «по-человечески» сделать скидку или отсрочить оплату. Потому лучше с самого начала держать дистанцию на уровне делового общения.
5. Главный бухгалтер: друг или враг
Об этой, на самом деле, очень распространенной проблеме, почему-то очень мало говорят. А ведь от того, как к подрядчику относится бухгалтерия, напрямую зависит, будут ли вовремя оплачиваться счета. Финансирование – важный аспект разработки или внедрения программного продукта. Мы еще не видели ни одного программиста, который смог бы писать код, при этом не есть, не пить и не оплачивать счета, в том числе, за электричество и доступ к интернету.
Если вы умудритесь стать личным врагом главного бухгалтера, даже прямое вмешательство руководителя компании может оказаться недостаточным для реализации проекта. Ваши счета всегда можно «потерять», на них может «не найтись бюджета», так как «средства ушли на более срочные выплаты» и т.д.
Как избежать проблем с бухгалтерией заказчика:
- Самый простой вариант – избегайте прямого общения в принципе. А все документы (оригиналы счетов, подписанные акты и т.д.) передавайте вовремя. Если ваша фамилия или название организации не будут вызывать негатива по типу «А! Это тот самый, который так и не передал акт и мешает мне закрыть период», проблем со стороны бухгалтера не будет.
- В случае разработки или внедрения программных систем для бухгалтерии, общения не избежать. Вам понадобятся консультации будущих пользователей. Изучите основы бухучета, чтобы говорить с бухгалтерами на одном языке. И помните, что вы отрываете от работы занятых людей, которым за общение с вами никто не доплачивает. А потому – цените чужое время и сведите консультацию к необходимому минимуму.
Конечно, не стоит забывать и о личных качествах человека, постарайтесь понравиться не только руководству, но и бухгалтерам, раз уж пришлось с ними общаться. Если вы – разработчик-одиночка, но при этом не отличаетесь коммуникабельностью, подумайте, может, стоит найти своего менеджера?
6. Зачем нужны прототипы
Большинство описанных выше пунктов подойдут для любого направления бизнеса. Что поделаешь, программисты делают такие же ошибки, как и все. И эти ошибки приводят к конфликтам и незавершенным проектам. Но этот пункт касается только разработчиков, причем, он нужен в случае создания программных продуктов с нуля.
Прототипирование – важный этап работы над любым приложением или сайтом. Прорисовка и согласование всех экранов помогает избежать логических ошибок, связанных с переходами от раздела к разделу. А еще экономит время разработчика, ведь заказчик выбирает вариант внешнего вида еще на этапе «набросков». И вам не придется вносить правки в код, так как «вот тут должно быть синенькое и не квадратное, а круглое».
Что важно при создании прототипов:
- Не ограничивайте себя. Рисуйте где удобно. Можно даже на бумаге. Главное, чтобы вы как можно быстрее могли перенести идею в визуальный вид.
- Первые прототипы могут быть совсем схематичными. Главное, чтобы была понятна идея. Лучше набросать несколько вариантов, а потом без сожаления отправить все, кроме одного, в корзину.
- Не затягивайте этот этап. И не пытайтесь создать десятки вариантов. Как говорится, лучшее – враг хорошего. У заказчика должен быть выбор, но – не такой, при котором будут «разбегаться глаза».
Нередко разработчики вообще пренебрегают этим этапом. В итоге, проект затягивается из-за постоянных переделок интерфейса, возникают конфликты и сложности. В спешке код получает массу «заплаток», становится все больше похож на «говнокод». Что также не добавляет плюсов проекту.
А потому обязательно создавайте прототипы и утверждайте их на начальном этапе сотрудничества.
7. Тестирование и снова сроки
Выше мы уже обсуждали, что сколько времени ни выделяй на создание программы, все равно понадобится именно столько плюс еще немного. В результате на финальной стадии возникает конфликт интересов: сдать «сырой» проект или просрочить дедлайн.
При выборе первого варианта разработчики надеются, что будут и дальше обслуживать программный продукт, и там, «под шумок», сумеют выловить ошибки и при помощи обновлений оперативно закрыть баги.
В реальности нередко случается, что критические ошибки замечают пользователи. Если это происходит в компании заказчика, появляются претензии и недовольство с его стороны. Конечно, вы все исправите. Но отношения будут испорчены. И при малейшей возможности проект передадут другим людям. Но это еще не самый плохой вариант.
Если вы пишете, например, мобильное приложение или онлайн-сервис какого-то стартапа, «сырая» версия может стать причиной «смерти» целого проекта. Возмущенные пользователи будут писать негативные отзывы и ставить плохие оценки. Конечно, вы все исправите. Но сумеете ли после такого провала завоевать доверие? Крайне сомнительно.
Потому никогда не сдавайте программу до завершения всех этапов тестирования. Лучше потерять часть оплаты, если это будет критично, чем получить репутацию «говнокодера», с которым лучше не связываться.
На самом деле, проблем и «подводных камней» при взаимоотношении с заказчиками намного больше. Все их описать невозможно. Да и нет в этом смысла. Если ваше сотрудничество будет оформляться документально, а вы покажете себя профессионалом, способным решить поставленную задачу, скорей всего, программная система увидит свет, а внедрение продукта пройдет без лишних проблем. А если все эти сложности общения с заказчиками вас совсем не привлекают, напомним, что для этого существуют менеджеры. С ними работать намного комфортнее.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]