По ту сторону проблемы
О, как же много сказано и написано о взаимодействии "программистов" и "заказчиков". Не удержусь, и тоже добавлю.
Алексей Мась не так давно написал в ЖЖ отличный пост про ошибки, который я возьму смелость интерпретировать по-своему. Тезисы такие: Ваши проблемы - это проблемы, от которых вам больно. Проблемы, от которых вам не больно - это не ваши проблемы. Решайте только свои проблемы.
Это не бесспорная позиция, но в данном случае я не хочу обсуждать ее. Я предлагаю использовать эту модель мировоззрения, чтобы кое-что понять.
Какие классические проблемы возникают у программистов с заказчиками? Не надо особенно выдумывать - об этом написано на каждом втором программистском блоге. Заказчики капризные, часто меняют требования, вносят дополнительные задачи, не понимают тонкой душевной организации программиста. О чем мечтают типичные программисты? Строго формализованное подробное ТЗ, и чтобы его оставили в покое, пока он все не сделает. Какие проблемы у заказчика? Программисты делают не то, что он хочет, отказываются вносить изменения, пишут глючный код, срывают сроки, за равные внешне изменения требуют разную оплату.
Ключ к разгадке лежит в тезисах о проблемах. Какие проблемы могут быть у заказчика? Разные, в общем, но есть типичные: необходимость в компоненте для бизнеса. Возможно это ключевой элемент, возможно какая-то сопутствующая часть. В таком случае необходимость в работе с программистом для него - это решение проблемы достижения. Есть цель для достижения которой необходимо сделать что-то. Это что-то стоит между ним и целью его компании, к которой он ее ведет. Но бывает и по-другому, когда заказчик - нанятый менеджер, цели компании для которого примерно также важны, как и для программиста - то есть, чисто номинальны. У него проблема в том, что если все не будет сделано в срок - ему придется выгребать. Его начальник устроит ему экзекуцию. А начальник, между прочим, тоже может быть не последней инстанцией. Вы даже не представляете, насколько длинна может быть цепочка. Где цель? Ау? Что делаем-то? Как что - менеджеры ставят нам цели (и определяют наши проблемы)!
Какие мотивы программиста? Он, как правило, зарабатывает деньги, плюс - самореализуется. Самореализация в данном случае происходит внутренне, как у поэта - не так уж важно, как там дальше все будет, прикольно сделать систему как таковую. Чтобы все работало, летало, упруго звенело. Программист, особенно начинающий, часто получает от работы больше опыта чем денег. Он стремительно развивается на своих достижениях и ошибках. Он растет, стремится к совершенству. Ну, и заодно, конечно, получает неплохую зарплату.
Вы уже чувствуете, что я хочу сказать?
Заказчик и программист только внешне делают одно дело. На самом деле они решают совершенно разные проблемы. И более того, очень часто, во всем многообразии проблем, которые решают эти люди нет исходной цели разработки того, что они разрабатывают. А знаете почему? Потому что ни у кого из них от этой проблемы не болит. У них масса боли, но от других проблем.
Возьмем классическую проблему заказчика - фрилансер, взяв обязательства, и сделав даже часть работы, внезапно пропадает с радаров. Просто исчезает. Нехорошо?
Давайте подумаем. Что это для фрилансера? Взял работку, подколбасить на досуге. А тут - что-то времени стало мало, наверное это была плохая идея. И пропал. Ну черт с ними, с деньгами, не умру с голоду.
Что это было для заказчика-менеджера? Черт, сроки - они теперь точно не выполнятся. Деньги, хорошо, хоть не успели заплатить. Но что теперь делать? Искать нового? А он не пропадет? А с тем, что сделано, как быть? Новому покажешь - почти наверняка получишь ответ "это надо переписывать". Эх, плакал мой месячный бонус.
Что это было для заказчика-предпринимателя? Новая система не запущена, из-за нее нельзя запустить и новую рекламную кампанию, через месяц начинаются новогодние каникулы, а значит до февраля будет бизнес-спячка, то есть запуск по факту откладывается на три месяца. Это означает, что надо уволить трех человек их пяти, потому что платить им зарплату будет нечем. А возможно, и закрывать проект, потому что его банально "нечем кормить". Понимает ли это фрилансер? Даже если он не фрилансер, а наемный сотрудник?
Тот, кто действительно решает самую_главную_проблему (его принято называть предпринимателем) привлекает для этой цели многих других людей. Потому что в одиночку это физически невозможно - слишком много граней надо отполировать. Но другой человек - это всегда другие проблемы, другие мотивы.
Попытайтесь понять заказчика. Вас же не нанимают для программирования. Вас нанимают для решения проблемы. Если вы решаете не эту проблему - вероятно, рано или поздно вы придете к конфликту (а может, и найдете удачный симбиоз). Для предпринимателя проект - как ребенок. Если бы вы искали для своего ребенка няньку - как бы тщательно вы ее выбирали? Как бы вы отнеслись, если бы она вдруг оставила вашего ребенка и пошла пивка треснуть? Что, если она решит, поленившись, не погулять с ним парке, а запереть на балконе?
Хуже, если заказчик менеджер, но вам же все равно работать с ним. Решайте его проблему, вас именно для этого нанимают. Он, в каком-то смысле, раб ситуации, как и вы. Сложно сказать, что именно будет его проблемой - может быть сроки, может быть качество, может быть регулярность отчетов. Но они будут, гарантирую.
Главное, что надо понять - вас нанимают не для программирования. Любого человека, не только вас. Нанимают - всегда для решения проблем. Просто думают, как именно их решать, и ставят уже соответствующее задание. Задание - это не цель найма. Цель - решение проблемы, часто - уже обдуманным путем.
Не всегда подмена целей проблемами плоха: взять хотя бы армию. Строить большую компанию без элементов армии - практически невозможно. Ведь как-то надо заставить всех жить одной проблемой?
Но ваши проблемы - это те, от которых вам больно. А проблемы, от которых не больно - не ваши проблемы. И люди не склонны решать не свои проблемы. Так что, проблема, боюсь, вечна. Но те, кто это понимает - умеет строить правильный симбиоз. Ведь как-то же получается сделать то, что мы видим и чем пользуемся каждый день?
P.S. Процитирую М.М. Жванецкого - "Как шутят в Одессе":
Бригадир: Секундочку. Вы услышите наше звучание - вы снимете с себя последнюю рубаху. Эти люди чувствуют чужое горе, как свое собственное.
Жилец: Я прекрасно представляю.
Бригадир: Встаньте там и слушайте сюда. Тетя Маня, прошу сигнал на построение. Толстая Маня ударила в тарелки и посмотрела на часы.
Бригадир (прошелся кавалерийским шагом): Константин, застегнитесь, спрячьте свою нахальную татуировку с этими безграмотными выражениями. Вы все время пишете что-то новое. Если вы ее не выведете, я вас отстраню от работы. Федор Григорьевич, вы хоть и студент консерватории, возможно, вы даже культурнее нас - вы знаете ноты, но эта ковбойка вас унижает. У нас, слава Богу, есть работа - уличное движение растет. Мы только в июле проводили пятнадцать человек.
Теперь вы, Маня. Что вы там варите на обед, меня не интересует, но от вас каждый день пахнет жареной рыбой. Переходите на овощи или мы распрощаемся. Прошу печальный сигнал.
(Оркестр играет фантазию, в которой с трудом угадывается похоронный марш).
Жилец (аплодирует): Большое спасибо, достаточно.
- Блог пользователя Sniff
- Войдите или зарегистрируйтесь, чтобы оставлять комментарии





Комментарии
Нужно работать с такими людьми, у которых «болит» тоже самое. Хотя бы частично.
А еще можно «навязать» свою боль другому, вникнуть к нему в мозг, заставить его проникнуться такой же болью. Надолго. Чтобы рядом остался и помогал.
Или сделать свою боль болью другого человека посредством существующих инструментов. Описание такого «инструментария» может быть темой новой статьи.
Ну, скажем, выслушать человека, немного скорректировать его точку зрения, сманипулировать его мысли в правильное русло, объяснить боль, помочь этой болью посильнее проникнуться, заинтересовать решением проблемы, закрепить все это предложением доли «выхлопа», и человек твой. Возбудить интерес, внимание и боль не сложно — сложнее их удержать. Для этого вектора ваших путей должны указывать хотя бы в одном направлении, если не в одну бесконечно-удаленную точку. Это сложно.
Для себя пришел к выводу: время нужно делить на billed & not billed, так вот в те часы, которые выставляются заказчику ни о какой самореализации и проф росте речи быть не может. Я учусь писать внятные таски и ТЗ, разрабатываю систему, улучшаю поддерживаемость кода, структуру репозитория - но это не значит, что заказчику это нужно. Заказчику нужно: выполненный в срок таск, срочная доработка еще незаконченного таска, бросание очередного (н-го) начатаого таска и старт нового таска. За это он и платит.
А то, что моих советов не слушают часто, как оптимально делать проекты - атк это нормально. Всегда так было и будет, даже если в команде матерый ПМ и заказчик айтишник.
Это не проблемы, это просто непонимание, что так и должно быть. Каждый выполняет свою роль. Полет нормальный.
ах какая статья!
чувствуется боль автора.
особо понравилось про "упруго звенело".
нужно больше общаться чтоб человек проникся твоей болью, четко знал цели, чтоб лучше выполнять задачи.
Ярко, Мегазачетно) Прочел с большим любопытством. Леша жги книгу, я куплю первый)
не, не первый)
складно излагаешь!)
у меня есть предположение, что каждый программер, который берется выполнять задание, хочет сделать его если и не совершенным - то по крайней мере предусмотреть разные возможные будущие правки.
Код который написан тобой, подобен ребенку - это тоже частичка тебя, которую ты лелеешь и хочешь чтобы она стала одной из самых лучших.
Скажи программисту честно: - ты ждешь от него лишь работы заложенной функциональности в максимально возможные сроки! Главное стабильная работа этого небольшого кусочка.
Это половина правды. Важно понимать, что "работа заложенной функциональности в максимально возможные сроки" - это его видение решения его проблемы. Скорее всего, оно правильное, но это не цель - это путь решения. И ждет он решения проблемы, достижения цели. Она на шаг дальше, чем задание.