×
Фото Программист — это тот, кто не нужен заказчику

Программист — это тот, кто не нужен заказчику

На первом курсе на одной из первых пар по операционным системам преподаватель сказал: «Операционная система — это то, что ненужно пользователю».

На первом курсе на одной из первых пар по операционным системам преподаватель сказал: «Операционная система — это то, что ненужно пользователю».

Немного перефразировав, я получил заголовок этой заметки. И здесь нет ошибки — программист не нужен заказчику ровно на столько, на сколько ОС не нужна пользователю. И даже больше: программист только ломает сайт, делает его уязвимым…

Поясню свою позицию.

Разработка

Когда заказчик хочет получить сайт / приложение для телефона / программу для рабочей станции («компьютера»), заказчик взаимодействует с менеджером по продажам. Необходимость продавца понимают все — все ходят в магазины, покупают вещи.

Далее — менеджер по проектам описывает формально проект, пишет тех. задание. С ним же и будет взаимодействовать наш абстрактный заказчик: просить добавить функциональность сайта, требовать исправить что-либо.

После описания проекта, написания тех. задания, начинают работать программисты, дизайнеры и прочие люди, которые разрабатывают сам продукт.

При чём заказчик может хоть сколько-то оценить только работу дизайнера — то что он видит, то, в чём, как он думает, он разбирается.

Работа же программиста для заказчика — в лучшем случае «магия». В худшем — он даже не подозревает о ней. А что, ещё на этапе проектирования всё было описано — что тут ещё делать? Максимум, что он может оценить — это красиво раздвигающиеся менюшки и прочие свисто-перделки. Но это же дизайн! Зачем тут программисты?

Далее, когда «всё закончено», наступает время, когда заказчик начитает понимать, что ему было нужно — звонок проджекту — проджект говорит: «всё починим» / «всё сделаем». И у заказчика появляется реальное ощущение того, что именно проджект всё это и делает. Об этом мне сама рассказывала наш проект-менеджер (Привет, Таня! :)). Подобная ситуация возникает и с дизайнерами. Но там опять же заказчик это видит. В случае программистов же — ну интегрировать ещё одну стороннюю библиотеку / проект — просто «поставьте это слева».

Эксплуатация

Во время эксплуатации продукт видят пользователи. Но они именно «видят» — их взору предстаёт дизайн. Хотя, тут, конечно, сложнее дизайнеру, ведь на выходе получается не то, на что способен дизайнер, а то, что нафантазировал / передумал заказчик. Код же может обругать только программист, который будет поддерживать его…

В общем, программист «существует» только для программистов.

Почему OpenSource проекты пишутся программистами и для программистов?

Минусы Open Source

Особенностью Open Source является то, что нет конкретного заказчика. Есть масса. То есть реализовывать надо не бред одного человека, а область пересечения бреда людей в массе + некоторую её окрестность. При чём, если в проприетарных проектах обычно всё происходит так, как это было описано выше, то в Open Source, обычно, реализуется только та часть бреда, которая ещё не противна. Разработчики не кинутся переписывать всю архитектуру, если проект не работает на Plan9 OS. Дизайнеры Creative Commons плюнут на Очень Известного Эксперта™, если они не будут согласны с его мнением.

Однако, заказчику нужно всё и сейчас. При чём каждому — своё. Потому Open Source остаются «поделками студентов», а Apple выпускает «самые лучшие компьютеры».

Программисты программистам

Как уже говорилось выше, труд программиста может быть оценён только программистом. Собственно, потому и приятно разрабатывать не проекты, а фреймворки для их выполнения. Программисты способны отсылать качественные bug-report’ы, оценить красоту «магии», быть благодарными за открытость кода.

Многие Open Source проекты живут только за счёт потребности в самореализации их авторов. Не получая её в другом месте, здесь человек может отвести душу. А зачем вкладывать душу в то, что не оценят? Поэтому «программистами и для программистов».

2013-08-06 09:56:46 annulen

>Особенностью Open Source является то, что нет конкретного заказчика

4.2 — в большинстве крупных Open Source проектов принимают участие программисты на зарплате у компаний, либо получают от них финансирование, как Майк Пол (LuaJIT), который ни на кого официально не работает, но получает ото всех деньги :) Эти проекты никогда не попадают в список «поделок для студентов».

Если же такого заказчика нет, заказчиком является сам разработчик. Например, я часто дорабатываю нужные мне фичи в опенсорсных инструментах, которыми пользуюсь. А вот когда open source пишется не для себя и не по конкретному заказу, получается GNOME 3 :)

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

Будь первым – оставь комментарий!

Фото Энтерпрайзный код — на чём писать?
Предыдущая запись:
Энтерпрайзный код — на чём писать?
Фото У каждого офиса запах особый…
Следующая запись:
У каждого офиса запах особый…

Интересное на «Цифре»

Фото 5 причин не исправлять "ошибки"
5 причин не исправлять "ошибки"
Сразу оговорюсь, речь пойдёт не о критических ошибках. Если ваш сервис лежит бездыханный, то конечно — ноги в руки и фиксить.
"Чайка-менеджмент". Опасности и злоумышленники
Не так давно мы рассмотрели анти-паттерн “Чайка-менеджмент”, однако, совсем забыли рассмотреть опасности для такого менеджера
Фото «Методологическое безумие» и «Scrum»
«Методологическое безумие» и «Scrum»
Пока в Москве повальное увлечение методологией “скрам” меняется на “бирюзу”, в регионах так и продолжают внедрять “скрам”. Оба эти увлечения обычно не приводят ни к чему хорошему. В конце концов всё приходит к “у нас скрам, но не совсем” или “скрам — говно”
Противление методологиям как методология
Забавное нынче время. Попы освящают дата-центры, детям преподаётся креационизм, а в командах разработки появилось новое обзывательство: “теоретик”