"Война - дело молодых" (с) В. Цой

Шикарная дискуссия развернулась на страницах Gazeta.ru Дискуссия между программистами и менеджерами. Хорошо что в online, в реале они бы уже наверное подрались. Это просто замечательный образчик войны стереотипов (для лучшего восприятия привожу обе части целиком, без купюр).
Итак, часть первая:

Что думают программисты о менеджерах

Программисты учатся
Это процесс нельзя прерывать. Некоторые даже могут себе позволить менять работу для того, что бы набраться опыта (skills'а) в новых областях. А это означает, что прием на работу программиста со стажем не гарантирует, что он на 105% подходит вам. Он прошел собеседование. Он ответил на какой-то тест. Выполнил пробное задание. Ну и что? Тест и задание было придуман за пол часа до его прихода. Это задание даже может не относится к тому чем человек будет заниматься (любят всевозможные интеллектуальные тесты или алгоритмы поспрашивать). А собеседование проводили человек, которым назвать "гуру" может только программист на QBasic.
Часто прожект менеджеры поверхностно знакомы с теми технологиями, которые должны применятся в проектах.

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

Они даже не задумываются, что их контора будет финансировать новоиспеченному сотруднику "глубинное бурение" в новые технологии. А человек поучится на вашем проекте и уйдет в другую контору. Там ему будут платить больше, так как другой менеджер по достоинству оценит его новые знания :) Из-за того, что квалификацию программиста трудно определить, некоторые работодатели уважительно относятся к различным сертификатам. И это, наверное, правильно.

Стартап для студента
Если вы менеджер то также должны понимать что, нанимая студентов не надо требовать скорости работы как у опытного программиста. Скорость будет ниже раза в 2-3. Они не тупые. Просто им тоже надо время на обучение. Вы также должны понимать, что хороший код у них появится только на 2-3 проекте. А когда вы счастливый сдадите их первый проект (который, разумеется, провалиться по срокам), то они, конечно, будут радоваться с вами, но и загадочно печально улыбаться. Они то понимают, что надо все переписать. Они, наконец, поняли, что построили не верную классовую структуру. Они теперь знают, как оптимизировать код (на форуме, за день до сдачи проекта, подсказали пару фишек). Могут улучшить его читаемость для дальнейшей разработки.

Но все это уже никак не влияет на ваш проект. Так что еще раз думайте при приеме на работу.

Оценка времениСкажите, как человек может точно оценить, сколько времени потребуется на проект, если он слабо понимает что предстоит делать. А прожект менеджер-уникум оценивает. Должность обязывает. Он составил ТЗ, разбил его составные части. Указал дидлайны и все. В бой.

Да он, конечно, посоветовался с программистом о времени.

Но через некоторое время программист узнает, что ТЗ это то, как видит систему заказчик и как понял все это ПМ. А вот жизнь и ТЗ это две разные вещи.

ТЗ поменялось. Сроки поменялись. А договор уже есть!!!! Надо как-то сделать в срок. Поздравляю, товарищ программист, будет работать у нас в выходные!

Выставляйте заказчику время в 2 раза больше запланированного (ну или хотя бы отталкиваетесь при переговорах). Это очень тяжко проходит, когда оплата почасовая, но, скорее всего вам столько времени и понадобится. При этом срок для программистов должен быть тот, который вы с ним утвердили. За слова надо отвечать. Но помните что отладка и багги - это естественный процесс. И если бы вы программировали вы бы это поняли : Будьте спокойны и относитесь к ошибкам философски. Рассчитать время отладки трудно, но это примерно 30 - 40% от всего объема работы.

Также не рекомендую оценивать время на глазок (о ну наши ребята такое писали!! Сделаем за месяц).

Мало однотипных проектов. Всегда есть свои тонкости. Страхуйтесь. Одно неверное слово менеджера - это неделя работы для программиста.

Любимый заказчик
Еще есть такая чудесная особенность заказчика, которую можно охарактеризовать фразой: "сам не знаю что хочу, но хочу". Т.е. что-то в шальной голове сформулировано, но довольно аморфно. Тут придется выезжать на место. Брать заказчика за шиворот и проводит допрос, похлеще гестапо.

Но это не означает, что все вам расскажут (по фильмам мы знаем: наши люди в гестапо молчали).

В конечном итоге все факты всплывут, но время… Время будет не на вашей стороне. Да, да… выходные. Держите заказчика на "коротком поводке". Опросили. Набросали ТЗ. Утвердили. Набросали GUI. Утвердили. Написали болванку-интерфейс без функционала. Утвердили. И т.д. Побольше промежуточных версий. Пусть заказчик чувствует ваш пот и кровь ;).

Делегирование обязанностей программисту
Я понимаю… у вас нет тестера, техпис уволился, аналитик заболел, дизайнер в творческом кризисе. Но с чего вы взяли, что программист выполнит их работу хорошо? Вы ведь не пытаетесь заставить всех этих людей программировать.

И еще совет ПМ'ам - больше учитесь. Хорошие прождет менеджеры так редки, потому что они должны быть программистами, психологами, финансистами, людьми с амбициями. А зачастую - это только люди с амбициями. Удачи.

Итак это был замученный программист. А теперь, обиженный и нагловатый менеджер.

Что думают менеджеры о работе программиста

Позвольте не согласиться и изложить как видятся некоторые пункты с точки зрения менеджера.

Учёба
Хотите учиться – учитесь! Но! – в свободное от работы время. Если Вас застукают с изучением, к примеру, Оракла, в то время как компания целиком и полностью работает на SQL Server – не взыщите, наказание будет жестким но справедливым – за разбазаривание времени и ресурсов компании на рабочем месте.

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

Заказчик
Простое железное правило: Нельзя выпускать программиста общаться с заказчикам. Никогда. Нигде. Во всяком случае, если ну очень нужно – только под контролем. Потому что душевная организация программсита ортогональна и неконгруентна целям бизнеса. Для программистов заказчик – это идиот с мешком денег, который даёт им возможность зарабатывать на жизнь, решая такие задачки, которые при других обстоятельствах программисты с неменьшим удовольствием решали бы бесплатно.

Делегирование
На самом деле программист может делать всё: и дизайн, и тестирование, и администрирование. Почему не делает? Ленив. Ему неинтересно.

Так что зачастую проблема менеджера – это не набрать новых людей, а заинтересовать, простимулировать (вариант: нагнуть) програмиста, чтобы тот выполнил требуююмую от него работу в рамках новой служебной обязанности.

P.S. Уважаемые господа программисты. Не тешьте себя иллюзиями: менеджер знает о программисте гораздо больше, чем сам программист. В том числе и то, что программист по природе своей ленив, но любопытен. Что хороший программист может работать и по 12 и по 14 часов в сутки, показывая сумасшедшую производительность.

Что любой проект может быть завершён за 1/2 отпущенного срока. Что для программиста лучший отдых – это смена рода (роли) деятельности. И самое главное – что нет уникальных, незаменимых программистов.

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

Соответсвенно, больше ценится тот, кто больше знает и умеет лучше управлять – кем? людьми, а не компьютерами.

Я когда-то работал в компании, где все так и было. Программисты в своем кругу обсасывали менеджеров, а менеджеры между собой, примерно в таком ключе обсуждали программистов. И тогда я думал что это диалектика, закон природы такой, по Дарвину. Или по Киплингу: менеджеры есть менеджеры, а программитсы есть программисты. И вместе им никогда не сойтись.
Сейчас я понимаю, что просто в той компании был бардак. И такое положение вещей не редкость, к сожалению.
В своих филиппиках неправы оба. Однако, когда программист не особо разбирается в вопросах менеджента - это нормально, и простительно. Но когда менеджер не демонстрирует полное непонимание вопросов управления процессом разработки - это либо глупость либо провокация.
Нормальные методики разработки были придуманы, в том числе, и для разрешения подобных противоречий.
Сейчас я работаю в фирме где менеджеры не оценивают длительность проектов и никого не "нагинают", а программисты не выполняют работу тестировщиков и аналитиков. Где обучение программистов зарание планируется, равно как и обучение менеджеров. Не рай конечно, но я могу читать эти "мнения" просто с улыбкой. А вы?