Программисты vs Заказчики

Ноя 3, 2009 Программирование

Сегодня на блоге Лелика прочитал что во всех бедах заказчиков виноваты программисты. Люди это в большинстве своем ненадежные, кидалы и просто ходячее пособие по распиздяйству. Можете считать все что ниже ответом разгневанного программиста:

1. По хорошему между программистом и заказчиком должен находиться еще как минимум проектный менеджер. Проектный менеджер это человек понимающий заказчика и программиста (грубо говоря это аналог совкового технолога способный невнятное лепетание заказчика перевести в простые логические конструкции).
2. Т.к. менеджеров у нас нет, а там где есть дорого, то заказчики идут к частникам. Частник лицо анонимное, на данный момент у нас школьник за 2 недели прочитавший книжку по пхп уже считается программистом. Здесь важно понимать, что большая часть провальных проектов именно на это и напарывается. Понимаете, в программировании есть понятия проектирования и кодирования. Книжка по пхп дает понятие о кодировании, но не учит алгоритмистике, не объясняет паттернов, не дает устойчивых конструкций.

Вообще большая часть из присутствующих на рынке сегодня программистов ниже среднего уровня (чтобы было понятно себя со своими около 10 годами опыта промышленного и коммерческого программирования я отношу к разделу чуть ниже среднего). У нас много кодеров, но мало архитекторов. Даже изучая исходные коды большей части крупных веб систем на сегодняшний день понимаешь что код и архитектура находятся на доисторическом уровне.

3. ТЗ превращается. По моим оценкам порядка 40-60% проблем на рынке фриланс программирования приходится на нечеткую постановку задачи. В ходе начала работы ТЗ начинает мутировать, расти, меняться в итоге на выходе получается совсем не то, что заказывали. Причины я думаю всем понятны, в ходе работы заказчику очень хочется добавить пару удобных вещиц, присобачить еще вот это, на середине проекта понять, что ошибался и переделать заново и т.д. При этом на все заявки программиста о том, что цена меняется начинаются вопли, мол обирают нас и работать вы не умеете.

4. Неумение формулировать задачу. Второй проблемой с ТЗ является неумение заказчика объяснить что он хочет. Очень часто заказ носит характер показа страницы или скрипта и вопля мне нужно вот это но не так. Здесь сходу можно оценить уровень программиста на которого вы наткнулись. При неясных вводных нормальный исполнитель запросит как минимум пару примеров входных и выходных данных. На основе этой информации можно попробовать прикинуть, как работает потенциальный заказ. Проблема в том, что мы не Кашпировские и знать что происходит в фантазии заказчика не можем. Проблема решается прототипированием — сбором минимальной конфигурации рабочего примера и последующим обсуждением с заказчиком что так, а что нет. Это естественно требует времени. (подробнее об этом ниже).

5. Я не знаю ни одного проекта сложнее 2+2 который писался бы с первого раза. Любой проект в рамках сущесвтующих систем управления разработкой проходит несколько обязательных этапов. Агиле жестокая штука. Без прототипа вы не выйдете на альфу. Без альфы нет беты. Без беты сложно прыгнуть сразу на релизкандидат. Ну а от релизкандидата до релиза уже рукой подать. В ходе этих этапов разработки программист и заказчик вырабатывают общее видение разрабатываемого продукта и начинают хоть как-то друг друга понимать.

6. Наиболее производительные спарки — хорошо притерты. При длительной работе с программистами на каком-то этапе заказчик все же мутирует в подобие проектного менеджера, правда программист тоже частично в него мутирует, тем самым они вдвоем заполняют имеющуюся брешь в процессе разработки. Многие заказчики часто входят в заблуждение что если они успешно работают с одним программистом, то эта же схема будет работать и на другом. Это заблужение. Программист не БМВ, уровень мастерства, опыт и понимание у каждого разные. Факты понятные изначально одному, могут представлять собой темный лес для другого. Именно поэтому я считаю наилучшим вариантом длительное сотрудничество подобных пар (для примера я работаю, правда уже с партнером, над проектом порядка полугода. За полгода мы научились как-то понимать друг друга).

7. Программисты работают лишь 30% времени в день. Господа, я открою вам секрет, 30% это очень большой показатель. Ваши вечные жалобы что программисты лишь в пустую тратят ваше время и бабки — ошибка. Программирование (именно программирование, а не кодинг) это не гайки на заводе закручивать. Любой программист, как и писатель 90% времени думает и лишь 10% времени пишет. Если программист не будет думать, то вы получите тонны кода, который будет либо не оптимальным, либо нерабочим, либо просто не там где надо.

Все выше имхо, но близко к истине. Думайте. Комменты в тему приветствуются.

Рекламный блок
Топографию в школе слышали? Все виды топографических работ и услуг в одном месте. Топографические работы проводят истинные мастера своего дела с богатым опытом и не скудным внутренним миром. Заказывайте пока дешево.

Предыдущее сообщение: Интервью
Следующее сообщение: Свинной гриб на Украине

Метки: заказ, программирование, фриланс