Взаимодействие с подрядчиками — как улучшить работу с программистом
Введение
А в целом, стоит ли вообще пытаться улучшить это взаимодействие с разработчиками? Почему это заказчик должен еще и об этом думать. Заказчик платит, так пусть разработчики и думают как улучшить это взаимодействие, верно? Неверно.
Почему для заказчика ВЫГОДНО иметь эффективное взаимодействие и хорошие отношения с разработчиками.
Если отношения хорошие и взаимодействие построено грамотно:
- работать будут быстрее, точнее (разработчик не будет постоянно прикрывать свою .опу от санкций заказчика);
- разработчики будут предлагать решения, которые заказчик сам не в состоянии учесть;
- разработчик не будет перестраховываться в оценках по бюджету и сроку (на случай если заказчик начнет выкидывать фокусы по изменениям требований в процессе работы).
Если плохие отношения:
- программисты перезакладываются (понимают, что заказчик будет выжимать по максимуму);
- начинают делать строго по ТЗ, а не как лучше для проекта;
- постоянно подстраховываться, согласовывают каждый чих с заказчиком, чтобы потом в случае проблем тыкать в "вы же сами это согласовали";
- избегать лишнего взаимодействия (уменьшение общения до минимума, долгая обратная связь);
- вообще ничего не предлагать по проекту в плане улучшений.
Далее мы разберем элементы, которые позволяют улучшить это взаимодействие. Это должно идти как от разработчика, так и от заказчика.
Конфликтность, крикливость, истерики при общении и поиск виновных или честные открытые отношения
Это сильно упрощает программисту жизнь, когда не нужно постоянно разгадывать полунамеки клиента в плане негатива. В нашей практике были такие клиенты, которые постоянно держат в полунапряжении без каких-то конструктивных решений. Обычно это рамка проблемы (кто виноват, почему так вышло и т.д.). Т.е. задача не в быстром движении вперед, а в выяснении отношений и поиска виноватых. Работать над такими проектами очень некомфортно и совершенно неэффективно. Вместо написания код под проект и проработки заданий, время тратится на бесконечные коллы ни о чем.
Если же отношения нормальные, конструктивные и все недомолвки говорятся сразу и доброжелательно - все гораздо упрощается, нет этого давлеющего эмоционального фона. Ошибки бывают. От этого никуда не деться. Именно они часто становятся предметом таких микроконфликтов.
Если каждая ошибка превращается в конфликт с темой Кто виноват, программист просто будет искать способ выхода из подобного проекта.
Важно договориться о нормальном взаимодействии для быстрого решения проблем и минимизации подобных ошибок.
Лить воду или давать сжато конкретику
Время - деньги. Особенно для программистов. Не нужно тратить время программистов на шелуху и просто болтовню.
Формулируйте конкретно свои пожелания. Чем точнее вы понимаете, что вы хотите, тем быстрее это сделают и это будет дешевле (меньше нужно времени для обработки пожелания).
Некоторые любят приседать на уши менеджеру или разработчику. Вместо написания кода для проекта заказчика разработчик слушает про экономическую ситуацию в стране. Для программиста его ресурс - это время. Не нужно разбазаривать этот ресурс попусту.
Если даете задачу программисту, сразу укажите значащие детали: скрины, адреса, логины. Он все равно это запросит для решения задачи - нет смысла заставлять его это делать. Сразу все дайте в одном пакете.
Нивелировать сложность работы программиста ("это же очень просто сделать") или уважать труд программиста
Некоторые заказчики пытаются манипулировать оценкой задачи, говоря, что это очень просто сделать. Они думают, что программист же не может признаться "это сложная для меня задача и смогу сделать только за 3 часа", и он согласится сделать это за 1 условный час. Эта манипуляция очевидна и неприятна, и она портит отношения.
Сразу возникает желание сказать "Если такой умный, то почему бы тебе самому не сделать за это время эту задачу, заодно и сэкономите немного".
Лучше действовать наоборот - подчеркивайте важность и сложность работы. Хвалите за хороший результат. Давайте конкретную адекватную обратную связь при неточностях.
А вдруг программист все же накручивает оценку? В этих ситуациях нужно запросить детализацию задачи.
Оценил он, например, задачу в 30 часов. Вам кажется много - запросите детализацию задачи по частям. Также сравните это с другими оценками в проекте. Другой вариант - иметь внутреннего тех специалиста, который может адекватно оценить сложность работ и требуемое время.
Если сомнения продолжают одолевать, рекомендуем посмотреть нашу статью Как программисты обманывают клиентов.
Давать идиотские советы, когда совсем не понимаете в области разработки или доверять разработчику решение технических вопросов
Зачастую клиент дает свои "дельные" технические советы из лучших побуждений. Но большинство таких советов неуместны, оторваны от реальности и не несут никакой пользы. Гораздо лучше действовать на своем уровне. На уровне заказчика. А именно - точно формулировать свои бизнес-потребности. Обосновывать их важность для бизнеса. Принимать взвешенные решения по сложным вопросам.
Если вы залезаете на территорию программа, то это похоже как пассажир самолета начинает давать рекомендации пилоту или хуже того, лезет в бортовую технику.
Опасным следствием для проекта может быть потеря разработчика. Когда тебе начинают давать дурацкие советы по твоей специализации от дилетанта - ощущения ниже плинтуса. Т.е. это негативно влияет на самооценку разработчика. Он может немного приуныть и просто уйти из проекта (в нашей практике такое было - клиент начал давать ценные замечания по запросам SQL, хотя при этом не имел даже базовых знаний по этой теме. В итоге мы потеряли хорошего разработчика).
Продавливать волю в проекте (пытаться обойти объективные ограничения непонятно за счет чего) или прислушиваться к разумным доводам
Если решение позволяет что-то сделать гибко, это совсем не значит, что нужно постоянно делать гиперсложные решения под лозунгом "я так хочу". Публика любит истории про Стива Джобса и его маникальное стремление к совершенству. Но это ошибка выжившего. А сколько таких джобсов так и не запустилось? 99% Почему не запустились - просто денег не хватило, либо решение слишком сложное и не особо нужное.
В любой системе есть свои объективные ограничения. Обходить их через костыли - плохая идея. Рано или поздно эти костыли обломятся и все упадет. Либо поддерживать такое решение будет сущим адом.
Когда система сильно наворочена каждого новое внедрение дается все тяжелее и дороже. Ставьте во главу угла простоту и органичность. Если новая возможность не укладывается стройно в вашу систему - не внедряйте ее.
И очень важно прислушиваться к доводам специалистов. Сильная воля - это хорошо, но без мозгов она просто погубит проект.
Постоянно торговаться или правильно подходить к оптимизации бюджета
Программист - обычно интроверт. Именно внутренняя направленность программисту позволяет ему концентрироваться на задачах долгое время. Не любят они торговаться. Если их постоянно поджимать - они либо найдут более простого заказчика (который не выносит мозг по каждой мелочи), либо найдут способ как уменьшить издержки за счет качества проекта.
Если вам нужна скидка, то она должна даваться за что-то. Заказчик может что-то предложить и попросить за это скидку.
Например, написать статью о работе над проектом или разместить ссылку у себя (реклама услуг разработчика). Либо заказчик может часть работ взять на себя (в теории красиво, на практике - не очень это работает).
Стоимость и сроки всегда можно уменьшить. Это делается за счет объема.
Нужно меньше бюджет? Давайте убирать часть работ. Главное, чтобы при этом смета была достаточно детализированной.
Что, если другая сторона проявляет негативные сигналы, описанные выше?
Во-первых, нужно понять, как вообще получилось так, что вы работаете с таким человеком. Т.е. надо улучшить свою систему фильтрации, иначе в будущем история повторится.
Во-вторых, надо постараться прояснить отношения, построить новые ожидания, договориться о соблюдении неких соглашений. В основном проблема возникает в разных ожиданиях и подходах. Важно понять в каких именно аспектах у вас идет различие.
В-третьих, если вас что-то кардинально не устраивает, всегда есть выход из взаимодействия. Но выход должен быть экологичный, чтобы ваш партнер вышел из них с минимальными потерями и дискомфортом.
У каждого есть свои принципы работы. Это нормально, когда вы не готовы ими жертвовать ради очередного клиента или исполнителя.
Посмотрите нашу статью о том как с минимальными потерями сменить разработчика для своего проекта.
Выводы
Исправив эти моменты, ваше взаимодействие с разработчиками (да и другими исполнителями) выйдет на новый уровень. Вовремя отслеживайте появление негативных факторов (как со своей стороны, так и со стороны партнера) и выкорчевывайте их сразу же. В этом случае ваш огород будет всегда давать хороший урожай.
P.S. Посмотрите нашу статью о дистанционном взаимодействие с программистом, чтобы не опасаться, что программист создает имитацию работы.
Источник: https://falconspace.ru/blog/kak-uluchshit-vzaimodeystvie-s-programmistom