О профессиональных мечтах разработчиков

268
Первоначально я хотел обойтись вообще без каких-либо вводных фраз. Написал первый абзац, перечитал и понял, что не получится. Слишком многое объединяет людей. Слишком многое их разъединяет. У каждого человека в смысле творческой реализации есть великая мечта. Или, если посмотреть шире, такая мечта есть у каждой профессии. Этакое общее представление о земном рае глазами среднестатистического водителя троллейбуса или разносчика пиццы. Но так как троллейбусы водить мне не довелось, выбор профессии мечтателя ограничен - это специалисты в области IT. Итак, начну почти без предисловий. Пропустим общечеловеческие и общепонятные ценности, необходимые представителю любой профессии, например такие, как место под солнцем в стабильно развивающейся компании и достойная (вот и еще один философский вопрос - достойная чего?) зарплата. Речь пойдет о профессиональных мечтах чернорабочих софтверного бизнеса – разработчиков.

1. Пунктик первый. Хочу делать достойные, имеющие подлинную, реальную ценность и качество вещи (здесь и далее в контексте профессии под словом "вещи" имеется в виду ПО - программное обеспечение). А кто ж не хочет?¦ - спросите вы. Не побоюсь пафоса, но я хочу приносить пользу людям. Не только в силу морального удовлетворения от процесса, сколько хорошо понимая, что за реальный результат не стыдно получать достойное вознаграждение. По широко известной статистике, в наше время распространяемой в виде IT-легенд и слухов, успешно (да и то с некоторой долей условности) завершаются всего 16% проектов. Остальные или умирают (несмотря на то, что конечный продукт может быть очень даже востребованным) или выживают, но влачат жалкое "полусуществование". Нельзя сказать, что целью неуспешных проектов всегда является создание никчемного и бесполезного ПО. Как правило, ровно наоборот. Но уровень востребованности (и, как следствие, например, финансирования) оказался ниже уровня , количества и качества проблем, подлежащих решению. Вывод: не хочу в безнадежные, умирающие, "странные" проекты, даже если там хорошо платят. В целом, у каждого свои собственные моральные ценности и они решают все, но хочется чувствовать себя реально полезным.
2. Пунктик второй. Никакого реинженеринга. Никаких старых (да и новых тоже), громоздких, страшных, глюкавых и пр. систем, которые срочно (просто очень срочно!) нужно переделать/подправить/залатать. Потому что суперспециалист Вася, который это делал до тебя, уволился из-за низкой зарплаты, а в его коде мы (менеджеры и боссы) ничего не понимаем. Причем, как правило, код (коего миллионы строк) совершенно нечитаем, в лучшем случае комментариев просто нет (в худшем они только мешают), а сами специалисты-создатели (которые все это начинали еще до Васи) давно умерли/спились/уволены/уехали в далекую благословленную Силиконовую Долину. Копаться в таком коде - не для меня. Пусть у высокооплачиваемого (по сравнению с простым исполнителем) менеджера болит голова о том, что делать с десятками и сотнями тысяч срок всего этого неуправляемого кода, написанного до вас… может быть хоть это заставит менеджеров не всегда все свои проблемы перекладывать на разработчиков? В общем, я согласен делать только качественные вещи со стройной архитектурой, логичной и ясной структурой и хорошо оформленным и документированным кодом. Кто за?
3. Пунктик третий. Никаких заказчиков (идиотов) и никакого общения с ними. Только коробочные продукты. Все баги считаются фичами, все фичи записаны на "золото" (на CD). Ах, у пользователей есть замечания/пожелания? Пусть звонят в службу поддержки, в следующей версии все постараемся исправить. Нервы разработчиков надо беречь, иначе это чревато еще более крупными неприятностями для пользователей…если они еще не в курсе.
4. Пунктик четвертый. Раз от реинженеринга мы отреклись, надо полностью отряхнуть его прах с наших ног. Речь идет об используемых инструментах: компиляторах, бибилитеках, программных средах, etc. С какой стати надо писать на каком-то древнем Делфи? Только потому что фирмой (или заказчиком) он легально приобретен? Ах, еще и предыдущая версия сделана на нем? На здоровье, только я буду использовать NET. Строители почему-то не сверлят отверстия в бетонных стенах ручными коловоротами. Вот и разработчик нуждается в современном, мощном и надежном инструменте. Владение таким инструментом кроме всего прочего делает его актуальным на рынке труда (за которым кстати надо постоянно следить).
5. Пунктик пятый. Начальство должно быть вменяемым и компетентным. Среди менеджеров проектов столько случайных, в общем-то, людей, что требуется наметанный глаз, чтобы отделить настоящего менеджера от притворяющегося или искренне считающего себя таковым:
Вид "менеджер мнимый", подвид "посредник". Работа с ним начинается с того, что он знакомит вас (как разработчика) с заказчиком. На самом деле, подобное личное знакомство вовсе необязательно, но раз уж менеджеру так захотелось.. Вы еще не подозреваете, в чем тут подвох? Знакомством с заказчиком вся "работа" данного подвида по проекту и закончится. При этом он будет искренне считать, что честно выполнил свою миссию, и теперь достоин ежемесячной (!) менеджерской зарплаты, в то время как весь реальный геморрой руководства проектом и "разруливания" общения с заказчиком ляжет на ваши девелоперские плечи. Не давайте таким менеджерам одурачить вас больше одного раза.
Вид "менеджер мнимый", подвид "родственник большого начальника". Он приходит каждое утро, здоровается со всеми девелоперами за руку. "Как дела?" - вопрошает. "Хорошо!" - бодро ответствуют разработчики. "Это хорошо!" - резюмирует довольный "босс" и уходит за свой ноутбук лазить по инету до конца рабочего дня. Он уверен, что именно в этом и состоит тяжелый и ответственный (объясните мне наконец: в чем конкретно (рублях, метрах, секундах?) состоит эта ответственность?) труд менеджера проекта. Вдруг (для таких "менеджеров" это всегда вдруг) в одно прекрасное утро ему говорят: "Плохо". "Ну, это плохо!" - тотчас выкручивается менеджер и задает первый гениальный вопрос всех менеджеров – "А почему плохо?". Настроение испорчено, и по инету в такой день он лазит не столь активно. Впрочем, в любом случае всегда будет найден и примерно наказан виновный (разумеется, из числа непосредственных исполнителей - разработчиков), а менеджер даже и умершего проекта успешно продолжит свою победоносную карьеру и в том случае если он не родственник директора.
6. Пунктик шестой. Сроки и великие вопросы. Сроки - самый больной вопрос всего "цеха". Разговор о сроках до боли напоминает известную программу "Угадай мелодию!":
- я сделаю эту задачу за 4 часа
- я за два
- делай !
В 50% случаев девелоперу прямо заявляют "все должно быть готово вчера!". Из оставшихся 50% в 30% говорят "как можно быстрее", а в остальных дают жесткие до полной нереальности сроки. При доминировании подобных подходов совершенно неудивительно, что качество ПО всегда (!) оставляет желать лучшего. Причем что характерно, когда работаю по индивидуальному заказу, непосредственно общаясь с
клиентом (тяжело, но надо), сроки почему-то не срываются. Конечно, клиент морщится, когда ему говорят что готово все будет далеко не так быстро как хотелось бы (рекомендации о величине закладываемого запаса могут быть различны, рекомендую минимум двухкратный), зато готово будет гарантированно всегда. Непосредственное отношение к срокам имеет второй гениальный вопрос всех менеджеров: "сколько тебе надо времени чтобы исправить эту багу?". Если б я знал, уже бы исправил. Больше тут сказать просто нечего.
Что касается сроков, то работать надо в компании, в которой четко представляют: а) или сроки, или качество, того и другого вместе не дано и б) прежде чем что-то сделать, девелоперу надо подумать. Думать в условиях лихорадочной спешки крайне опасно как для здоровья проекта, так и для своего лично.
Подводя итоги, жизнь у нас одна. Для разработчика почти вся она проходит в работе. Стоит ли так легко, как это мы обычно делаем, разменивать ее на ерунду? Долой демпинг мозгов! Разработчики всех платформ, присоединятесь к манифесту!
Нам очень важна ваша поддержка
Стать патроном Отправить деньги
20


Пишите нам на info@antijob.net

2 Комментариев

Создайте или войдите в аккаунт , чтобы комментрировать