Наблюдаю и разбираю множество конфликтов консультантов с программистами, когда они в паре работают над задачей.
Разные ситуации. Не совпадают представления и ожидания от обязанностей и работы друг друга. Это подкрепляется страхами и давлением от руководства. Кто-то ошибается, принимает неверные решения и не хочет признавать свои ошибки перед другими или, что ещё хуже, перед собой. Бывает, что не хватает опыта, каждому в своей мере. Часто утопические масштабные задачи оценены исходя из того, что консультант и программист знают функционал и архитектуру наизусть, а они оба видят это впервые.
А процесс обычно построен упрощённо так: консультант описывает, программист делает, консультант тестирует.
Далее начинается перекидывание недоописанных и недоисследованных недорешений с невнятными формулировками от консультанта программисту. Иногда откровенно сырые бизнес требования просто записываются консультантом и передаются без обработки программисту. Программист в условиях информационной недостаточности и ограниченной оценки делает то, что описано, чтобы это хоть как-то было похоже, без уточнения деталей, на которые нет времени. Иногда пытается что-то раскопать, но, чувствуя негативный блок от консультанта, в итоге передает что-то такое же непонятное согласно описанию на тестирование. Консультант начинает проверять что-то там отдаленное от описания и естественно сразу обнаруживает, что что-то не работает или вообще не сделано (часто оно и не было описано).
От этого добавляется негатива, задача идет на доработку, но информации для программиста не прибавляется.
Программист зажат между оценкой, давлением от консультанта и недостатком информации. Чтобы программисту грамотно сформулировать вопрос относительно задачи, надо изучить много кода, а это время, которого нет. Попытки отсылки консультанта на уточнения требований или работы существующего функционала также встречаются консультантом в штыки. Он также зажат оценкой, сроками, негативом от бизнеса, давлением руководителя и недостатком информации, необходимой для выполнения своей роли.
В лучшем случае программист и консультант все-таки договорятся, поймут и сформулируют те вопросы, ответы на которые необходимо получить для выполнения задачи, когда сроки выполнения уже неоднократно сдвинуты, а часы на разработку превышены в 3 раза. К этому моменту наконец-то стало понятно, что и как надо сделать. Но каждый уже получил свой набор минусов в кошелек и репутацию.
Это в лучшем случае. В худшем это дальнейшие разборки, обострение, смена исполнителей (одного или сразу двух) и ещё больше минусов для каждого.
Для наблюдающих за этим процессом сверху, для тех, кто создал или не предотвратил умышленно или случайно такую ситуацию, виноваты будут оба. Кто-то в большей, а кто-то в меньшей степени в зависимости от политической ситуации.
Словом, засада со всех сторон. Никому не выгодное противостояние консультанта и программиста. Не имеет значения, кто виноват больше.
Что вы делите? Что и кому доказываете? Какая цель?
Вместе сообща разверните ситуацию в свою пользу. Получите информацию каждый на своем уровне, сложите этот пазл и выработайте правильную стратегию в своих интересах. Никто не знает всех особенностей лучше вас двоих - пользуйтесь этим.
Если консультанту заранее известен программист, то имеет смысл при осознании задачи и описании решения согласовать его с программистом. Вместе посмотреть, разобрать, оценить, а главное двоим одинаково понять суть планируемой разработки. Когда вам двоим всё понятно, можно легко крутить комбинации для вашей совместной выгоды. Там уже не так важно, что в описании будет - чем сложнее и запутанней, тем лучше для вас. На этом этапе уже можно увеличить бюджет на анализ и описание.
Большую мутную задачу делите на части, выполняйте и тестируйте их отдельно, показывая промежуточные результаты и то, что процесс движется. При видимом движении запросто будут согласовываться новые оценки, сроки и расширение бюджета.
Если программист назначается уже после передачи описания в разработку, то в первую очередь свяжитесь и обсудите. Обозначьте совместно неясные моменты, кто что должен прояснить со своей стороны. Честно признайтесь себе и друг-другу, какие моменты недоработаны со стороны консультанта. Продумайте заранее, как будет проще согласованными действиями и едиными показаниями расширить бюджет на разработку и тестирование.
Обозначайте прямо и без стеснений затраты на анализ процессов, существующего функционала и архитектуры. Это необходимый минимум для построения правильного решения. Будьте единогласны в этом.
Консультант вправе просить себе в помощь программиста, для уточнения функционала по коду. Программист вправе просить помощи консультанта для понимания отражения процесса в системе или создания тестовых примеров для отладки. В вашем взаимодействии это происходит по инициативе помогающей стороны. Даже просить никого не надо.
Подсказывайте друг-другу какие-то особенности, которые помогут каждому быстрее и правильнее выполнить свою роль. Вы в одной лодке. Надо грести одновременно, чтобы двигаться по кратчайшей траектории. Но не забывайте
зачем и почему вы поступаете именно так.
Важны три момента:
1. Вы так нежно дружите не потому, что так правильно, не ради глобальных целей проекта, не для радости руководства, не для экономии бюджета, не для процветания компании и пр. Это все и так достигается автоматически. Вы действуете исключительно в своих общих интересах. У вас взаимовыгодная дружба. Вы не просто не засаживаете друг друга и не считаете чужой доход, а даже наоборот проявляете инициативу по дополнительным бонусам и поощрениям своего выгодруга.
2. Ваш сговор — это не обман. Благодаря ему вы вывезли эту мутную задачу, вопреки условиям, в которые были поставлены и бездействию руководителей. Во что это могло превратиться описано в начале этого поста. Благодаря вашим совместным действиям все пошло по благоприятному сценарию. Все довольны, включая руководство. И если уж они этого не понимают, то выпишите себе премию сами.
3. Когда только один понимает и принимает то, что тут описано, так не работает. Важны оба двое. Поэтому прямо сейчас поделитесь ссылкой на
Выгодружбу со своим сегодняшним выгодругом, чтобы не тратить время на лишние объяснения.