Психологический портрет программиста

Народная мудрость: «Если ты сделаешь что-то быстро, но плохо, никто не вспомнит, что ты сделал это быстро. Но все скажут, что ты сделал это плохо. Если ты сделаешь что-либо медленно, но хорошо, никто потом не вспомнит, что ты делал это медленно. Но все потом скажут, что ты сделал это хорошо».

Можете ли вы поручить своему лучшему программисту любую задачу? А если поручите, то сможет ли он блестяще ее решить? Ответ на эти вопросы лежит не только в формальной области знает/не знает, опытен/не опытен, но и в области психологии мышления. Задачу можно решить:

• Быстро и хорошо.
• Быстро и плохо.
• Медленно и хорошо.
• Медленно и плохо.

В зависимости от индивидуальных качеств, любого программиста можно отнести к одной из этих 4 групп. Но на самом деле, при классификации программиста, у вас будет выбор только между двумя категориями. Почему?

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

Тип работающих быстро, но плохо наиболее распространен. По моим ощущениям- не менее 60% от программистов, входящих в эти две группы. Эту категорию любит начальство и заказчик, потому, что они умеют прямо таки с космической скоростью клепать код. Именно, что клепать, так как такой код для дальнейшего развития вообще не пригоден. При модернизациях программ его либо полностью выкидывают, либо нанимают консультантов, которые чаще всего внешними косметическими мерами улучшают его. В таком коде, как правило, отсутствуют какие-либо проверки в функциях на корректность входных параметров, нет ни строчки комментариев и, чтобы избавится от надоедливых исключений (exception), густо натыканы их перехваты (catch) с пустыми операторными скобками. Такой код изобилует неожиданными "ходами" на ровном месте. Неожиданными, потому, что решение тривиальной задачи уже накатанным приемом решается вдруг каким-то умопомрачительным вывертом, который полдня разбираешь, а потом еще полдня цедишь сквозь зубы ругательства в адрес того м… который пару тривиальных и всем понятных строчек раздул в невесть что.

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

Второй тип- медленный пишут ПО, но код грамотный, с хорошими возможностями расширения. Код медленно пишется не потому, что они тугодумы, а потому, что предпочитают перед написанием кода продумать архитектуру порученного им участка кода, и приступают к кодированию когда в голове складывается во едино вся картина предстоящей работы. Их труды можно распознать в первую очередь по комментированию кода и широкому использованию абстракций. В результате их работы код состоит в множества функций, небольших по объему, но в самих функциях делается много вложенных вызовов других функций. И тут чаще ругаешься по поводу того, как загнул сильно мысль свою программист, что "без 100 грамм и не поймешь".

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

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

Про важность отдыха

Начну с такой истории в своей жизни. На заре своей трудовой деятельности работал я в небольшой фирмочке. За соседним столом сидел коллега лет 40. Я каждый день старался, выкладывался как только мог. Часто бывало, что приходил домой в 2-3 часа ночи. Я очень хотел заработать хорошую репутацию и сделать карьеру. И для этого считал, что важно работать лучше других, делать больше всех. Я внимательно следил, как продвигается работа у коллеги, опираясь в оценках своей работы на его результаты.

А коллега в это время никуда не торопился. Частенько выходил покурить, и там читал книги по полчаса, пил чаек. Тем не менее, когда подходил срок сдачи задания, у него все было готово. Я нервничал, что никак не мог толком оторваться от него по производительности, и увеличивал свои усилия для выполнения работы.

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

Я стал понимать, что не на пустом месте возникли статьи трудового кодекса: 8-часовой рабочий день, час на перерыв, 5 рабочих дней, 28 дней отпуска. И теперь, как тот мой бывший коллега, я предпочитаю пойти попить чаю, если мысль в голову не идет. Могу просмотреть телеконференции, почитать новости. И ничего страшного в плане моей работоспособности не происходит- у меня среднестатическая производительность.

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

Из своего опыта я вынес несколько правил (кстати, многие скажут про них, что это все "старые избитые истины"):

1. Соблюдайте трудовой кодекс: 8 часов поработали- остальное время отдыхайте. Не "шабашьте" вне работы- лучше направьте все свои силы в одно русло, достигая наилучших результатов в одном деле, и не распыляясь по куче мелких делишек.
2. Не сидите все 8 часов за компьютером- делайте перерывы, пейте чай, общайтесь с коллегами. Если мысли нет, то ее и не высидишь. По этому поводу великолепно написал Джоэль Спольски. Почитайте про его "состояние потока": http://russian.joelonsoftware.com/Articles/FireAndMotion.html.
3. Те, кто говорят, что могут работать по 8 часов непрерывно- лгуны. Доказано, что более 4 часов человек не способен сохранять концентрацию внимания. Об этом вам наверняка говорили на лекциях ОБЖ в ВУЗе, т.к. на данном факте строится график работы всех критически важных служб жизнеобеспечения. Если вы все же утверждаете, что трудитесь каждый день по 8 часов непрерывно, то понаблюдайте за собой: через несколько часов активной работы вам захочется в туалет, либо вы вспомните, что надо срочно, пока не забыли, поговорить в аське со знакомым о чем-то, либо просто захотите проверить почту, посмотреть погоду, вспомните какую-то новость и обсудите ее с коллегами. Все это вам будет казаться важным, частью трудового процесса, однако это мозг сам "находит поводы" расслабиться, т.к. в его работе наступил спад, и на первый план вылезли второстепенные вопросы, которые, по большому счету, можно было бы и отложить, но вам они вдруг показались важными почему-то ("пока не забыл", "пока не ушел" и т.п.).
4. Для работников умственного труда, в которым относится подавляющее большинство IT-специалистов, важны комфортные условия труда. Человек должен быть выспавшимся, не голодным, с достаточным размером оплаты труда, чтобы ему не приходилось думать о том, где достать денег. Не должно быть ни холодно, ни душно, без сквозняков, пыли и грязи. Без внешнего шума и беготни вокруг. Удобное кресло, хорошая техника. Это все совсем не дорого, а прирост производительности будет приличный. По своему опыту скажу, что как только я перешел работать из фирмы, где практикуют "open space", в фирму, где у работников даже не свой кубикл, а отдельный кабинет, то я реально увидел, что стал работать существенно производительней. Подробнее тут: http://www.alvosoft.com/itlife/2008/03/blog-post.html.
5. А еще я заметил, что лучше всего трудятся те, кто разнообразно отдыхает: ездит в турпоходы, на курорты, а не просто весь отпуск на даче с утра до вечера грядки пропалывает.

В общем, желаю вам приятного отдыха и продуктивного высокооплачиваемого труда!

Организация рабочего места за компьютером, профессиональные заболевания и гимнастика

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

О СанНиПе

Он НЕ устарел. Последний- 2003 года. Написан достаточно обобщенно, чтобы оставаться актуальным и сегодня по большинству вопросов. Интересно, что в нем прописано:

1. на одно рабочее место должно быть не менее 6 м2, 20 м3 (получается, потолки- от 3 м). Этим частенько интересуются в форумах.
2. Места ДОЛЖНЫ быть оборудованы перегородками высотой 1,5-2 м. Надо же, модные "open space'ы" вне правил! Согласен- с некоторых пор у меня аллергия на работу на открытых пространствах.
3. ДОЛЖНО быть кондиционирование, вентиляция и увлажнитель.
4. Рабочий стул (кресло) ДОЛЖЕН быть подъемно - поворотным и регулируемым по высоте и углам наклона сиденья и спинки, а также - расстоянию спинки от переднего края сиденья.

И даже набор упражнений прописан, вот например, упражнения для глаз:

1. Закрыть глаза, сильно напрягая глазные мышцы, на счет 1 - 4, затем раскрыть глаза, расслабив мышцы глаз, посмотреть вдаль на счет 1 - 6. Повторить 4 - 5 раз.
2. Посмотреть на переносицу и задержать взор на счет 1 - 4. До усталости глаза не доводить. Затем открыть глаза, посмотреть вдаль на счет 1 - 6. Повторить 4 - 5 раз.
3. Не поворачивая головы, посмотреть направо и зафиксировать взгляд на счет 1 - 4, затем посмотреть вдаль прямо на счет 1 - 6. Аналогичным образом проводятся упражнения, но с фиксацией взгляда влево, вверх и вниз. Повторить 3 - 4 раза.
4. Перенести взгляд быстро по диагонали: направо вверх - налево вниз, потом прямо вдаль на счет 1 - 6; затем налево вверх направо вниз и посмотреть вдаль на счет 1 - 6. Повторить 4 - 5 раз.

О Тривиальном

1. Кактусы на системном блоке от излучений от ЭВМ не спасают! :)
2. Не садитесь работать с грязными руками, например, после жирных пирожков.
3. Чем современнее, тем, как правило, лучше.
   Не должно быть физического дискомфорта за рабочим местом.
4. Не забывайте про отдых.

Мои правила

Без соблюдения данных пунктов я на предлагаемую вакансию не соглашаюсь:

1. Хороший, быстрый компьютер. Сегодня это не дорого по сравнению с зарплатой программиста. Даже в небольших городах, где зарплаты невысокие, стоимость компьютера- максимум 2-3 "провинциальные" зарплаты. Зато быстрый компьютер способствует тому, что называют "работа горит в руках".
2. Два монитора от 19-20 дюймов. Тоже способствует тому, что "работа горит в руках". Очень удобно на одном экране собрать второстепенные вещи, а на другом- окно IDE.
3. Не загроможденное место, так что надо ютиться в уголке, пробираясь туда бочком. Это угнетает, утяжеляет "процесс вхождения в поток" (см. Дж. Спольски). В ходе работы постоянно отвлекаешься, чтобы поправить сползший на мышку листик из стопки, при смене сидячей позы переставление клавиатуры сопровождается разгребанием места, подбиранием упавших вещей с пола и т.п.
4. Кресло обычное, вертящееся, регулируемое, желательно с подлокотниками, но необязательно. Важно, что спинка регулировалась. Ну, за нерегулируемую спинку кресла расплата наступает быстро- пару лет, и вот вы уже сидите на приеме у врача или сетуете друзьям, что спина болит. Когда я первый раз пришел на прием к врачу в районную поликлинику, врач по описанию моих болей догадался: "Вы- программист?" Короче, наступать на грабли, на которые наступило уже куча народа- глупо.
5. Стол самый простой- вообще без изысков, полочек, тумбочек. Буквально, столешница на ножках. Это мое личное предпочтение.
6. Достаточно просторная комната, где я буду либо один, либо 2-3 человека. Но никак не 10 человек. Ибо постоянное хождение, обсуждение, звонки телефонов сбивают с мысли. Спасают только наушники, но это не дело- изначально мешать работе никто не должен.
7. Кондиционер и окна. Не люблю комнаты без окон. Особенно зимой: на работу приходишь затемно, уходишь- уже темно, сидишь в замкнутом помещении. Получается в прямом смысле "света белого не видишь".
8. Чистый опрятный офис с хорошим санузлом и "бытовкой": кофе попить, поесть и пр.
9. Интернет без ограничений. Досадно бывает- ищешь по работе информацию, поисковик выдал ссылку с аннотацией, где, согласно краткой аннотации, есть именно то, что надо. А сайт заблокирован политикой фирмы.
10. Нормальный коллектив.
11. Достойная зарплата. Чтоб мне не надо было думать о шабашках и о том, как прокормить семью.

Заметьте, я не требую себе телефона, дорогого ремонта офиса (главное, чтоб опрятный был), комнаты отдыха, "корпоративок", дотаций на питание и транспорт.

Моя гигиена

Мои рабочие инструменты- глаза, мозг, руки. И я их берегу:

1. Глазам я делаю гимнастику уже на автомате каждый час, а то и чаще: поморгать часто, потом потом помассировать глаза пальцами, затем повращать зрачками, и наконец- посмотреть вдаль, отвести на 5 минут взгляд от монитора.
2. Мозг балую разжижающим извилины чтением журналов о путешествиях, разных странах. И кушаю хорошо. А вы можете хорошо на голодный желудок работать? Я не могу- поесть для меня важно.
3. А еще я регулярно потягиваюсь, верчу шеей, вращаю кистями рук. Прохаживаюсь по коридору, пью чай- отвлекаюсь от работы, чтоб снять напряжение.

Как просто, да? Вот и не забывайте про себя на работе: делайте перерывы, разминайтесь!

Ссылки

СанНиП:
СанНиП, 1996 г.
СанНиП, 1996 г.
СанНиП, 2003 г.

Эргономика и гигиена:
ixbit.com
Сайт врачей-аспирантов
Болезни от компьютера, профилактика и лечение
Журнал "Здоровье детей"

Поучительный пример неудачной модели торговли

Дернул меня черт в предновогодние дни пойти в магазин купить сканер. Название магазина я не скажу, но многие московские ITшники без труда его узнают по описанию. Магазин гордо себя относит к гипермаркетам, и известен не традиционным способом организации процесса покупок. Чтобы купить что-то в нем вы должны:

1. Если хотите ознакомиться с товаром пройти в отдельный зал, и дождаться там пока его вам не вынесут, и не дадут повертеть в руках.
2. Если вы четко знаете, что хотите купить, то этап 1 пропускаем.
3. Идете к аппарату и нажав на нем мышкой кнопку "Распечатать" получаете квиток с номером заказа.
4. Идете в зал, где установлены компьютеры. Ищите свободный, который не завис (а таковых там минимум процентов 30%), который не выключен (таких тоже много) и приступаете к фомированию заказа. Тут для живописности упомяну о мерзких грязных мышах, пыльных, никогда не вытираемых мониторах и об отсутствии клавиатуры (все через мышку делается, на экране есть виртуальная клавиатура) Ввели свой номер, набрали заказ, получили сумму. Идете в кассы. Например, автоматические.
5. Там опять же ищите, что работает (работающего примерно 10%), вводите заказ с помощью мерзкой грязной мыши, вставляете купюры в купюроприемник.
6. Автоматическая касса сдачи не дает, поэтому за сдачей вы идете в другую кассу, обычную, где уже живой человек выдает вам сдачу.
7. Потом ваш заказ автоматически отправляется на комплектование, а вы на большом экране смотрите свой номер. Как только появился, то идете к указанной стойке, где вам выдают товар, оформляют покупку.
8. Идете к охраннику, чтобы он расписался на чеке, чтобы вас выпустили.

Все, вы свободны.

А, да! Забыл еще сказать, что в туалет вход платный, через турникет. Если точной суммы нет, то рядом стоит автомат для размена денег. У вас еще не пошла голова кругом от обилия всех этих автоматов? Магазин расположен в огромном, видимо, бывшем цеху, и все пункты (набор заказа, касса, выдача) расположены в разных концах помещения. Внутри все пыльно, покосившиеся выцветшие рекламные плакаты, столовая в чисто совковом стиле. Декларированного там бесплатного WiFi я не обнаружил.

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

В обычные дни данная модель работает шатко-валко, но в рождественские праздники система просто не выдержала нагрузки. Каждая точка (квиток, заказ, оплата, ожидание, выдача) превратилась в "узкое горлышко". Везде приходилось стоять в очереди. В самом конце, на выдаче хвост очереди был просто умопомрачительным- 4-5 часов стояния в очереди. Уже перед моим подходом к стойке зависла БД в магазине кладовщики ушли на полчаса пить чай, пока БД ремонтируют. В итоге, я вышел таки оттуда через 6 часов со сканером в руках, с проклятиями в мыслях и со словами: "Ноги моей здесь больше не будет!" Я был не один такой. Вся очередь гудела и возмущалась. Это 100% провал. Рождественский пик продаж не использован был явно на всю катушку- многие, видя очереди, с порога разворачивались. Используемая модель торговли давала сбои, образовывались простои из-за поломок техники и нечеткого разрешения конфликтных ситуаций (если человек заявлял, что заказывал не то, то на разбор ситуации уходило много времени, притом очередь стояла). Разберем на этом наглядном примере ошибки организации бизнес-процесса и, в частности, автоматизации процессов.

1. Явно не учтен такой факт, что зачастую традиционный "ручной" бизнес-процесс при попытке его автоматизировать "в лоб", т.е. один к одному перенося "ручные" процессы на "автоматические" никакой выгоды не дает. Автоматизация открывает новые возможности для бизнеса, которые и надо использовать, а не копировать "ручные" процессы. Например, почему бы не сделать на терминалах выбора товара сразу и оплату его по банковской карте, web money, Яндекс.Деньги? Т.е. без всяких квитков, напрямую подхожу к терминалу, формирую заказ, оплачиваю его безналичным способом, мне распечатывается тут же квитанция на получение товара, система выдает мне примерное время ожидания, я жду и иду на склад- получаю товар. Если оплата наличными, то иду в кассу сначала. Получается максимум 3 этапа, вместо 7.
2. Система совершенно не протестирована на работу под нагрузкой. Как результат- в пик продаж система начала давать сбои, что, несомненно привело к потерям денег.
3. В автоматизированной системе отсутствовало резервирование как класс! Магазин, который высоко автоматизирован, и не имеет резервных систем! Т.е. любой сбой, компьютерный вирус, отключение электроэнергии, прорыв трубы отопления в серверной приведет к остановке торговли, а значит к прямым потерям денег.
4. При автоматизации потеряны ряд методов "офлайной" торговли. Например, часто при покупке одного товара рядом на полках располагают сопутствующие товары (типа "пиво- сухарики"). При формировании заказа отсутствует подсказка вида "С этим товаром часто покупают то-то, то-то...". Отсутствует подборка статей о товаре с других сайтов, форумы и прочее.
5. Юзабельность близкая к нулю. Набор букв на виртуальной клавиатуре мышью вывело из себя и меня, весьма спокойного в жизни человека (поверьте, меня можно использовать как мерило спокойствия :) ).
6. Дружественность нулевая. Я пришел покупать, а с меня еще и деньги за туалет берут. Притом, грязный и забитый. Пример: Макдональдс, Икея- постоянно чистят и бесплатно. Столовая совковая, куча неисправных терминалов.
7. Уважение к клиенту- нуль. Пыль, грязь- общий вид какой-то разрухи, бестолковости.
8. Автоматизация, "обездушивание" процесса не означает, что и к клиенту тоже можно относиться бездушно. Наоборот все- чем больше автоматизация, тем более внимательно и дружелюбно надо относиться к клиенту. Тут примером может послужить печальная история бренда "Альфа-экспресс".
9. Использованы собственные решения- я бы часть системы отдал на аутсорсинг. Например, купил бы систему поиска товара, описания и выбора у Яндекса. У него есть очень удачный и мною любимый Яндекс.Маркет делающий все это гораздо лучше чем их система. Оплату- assist.ru.

Мое резюме. Магазин держится в основном за счет удачного месторасположения. Будь они расположены за пределами МКАД, как Мега, они бы не выжили. Низкое, совковое качество обслуживания, крайне неудачная система автоматизации, вообще не учитывающая никакого опыта... Ну что тут еще сказать?!

Нужны ли компаниям талантливые программисты?

В статье «Как проходить собеседование» я описывал, как компании производят набор сотрудников, и у меня возник вопрос: «А насколько полезны талантливые программисты компаниям? Какой метод можно использовать для оценки полезности программиста в компании?» Ответы на вопросы хотелось бы получить не в плане общих рассуждений, а в плане, пусть и грубого, но экономического расчета. Т.е. насколько оправданы затраты работодателей на сложные собеседования и тестирования кандидатов на вакантное место. Подозреваю, что ответ на вопрос прекрасно известен руководителям, озвучивается на разных семинарах, но в мир программистов данная тема не проникает. Много у программистов в этом плане заблуждений. Являясь одним из представителей этой славной профессии, я, зачастую, принимаю эти заблуждения за истину, и очень горжусь исключительной важностью своей работы. Прав ли я?

Для начала возьмем такую четкую, формализованную цепочку:

1. Программист, пишет код и ничего его больше не интересует.

2. Тестировщик берет код у программиста и тестирует его, в случае ошибок, возвращает код на исправление.

3. Менеджер по продажам берет у тестера готовый дистрибутив и продает его клиенту.

4. Клиент использует программу, и в случае проблем с программой обращается в службу технической поддержки.

5. Техническая поддержка работает только с клиентом, отвечает на его вопросы, и плевать им на остальные отделы. Пожелания отправляет программистам.

Пока так, без усложнений. Все занимаются своим основным делом, и не общаются друг с другом через отдел, например, менеджер по продажам с программистами не общается, а только с клиентами. Цепочка однонаправленная. Посчитаем, что получается. Пусть средний программист НЕ допускает ошибку с вероятностью 0,5. Обычный средний тестировщик найдет эту ошибку с вероятностью 0,5. Менеджер сможет продать клиенту программу с вероятностью 0,5 (хотя, наверное, это очень высокая вероятность). В итоге у клиента окажется на руках наша «глюкавая» программа с нашей искомой ошибкой с вероятностью 0,5*0,5*0,5=0,125. Клиент может НЕ наткнуться на ошибку в программе в среднем, ну пусть, тоже с вероятностью 0,5. И, соответственно, техническая поддержка поможет клиенту пофиксить ошибку с вероятностью 0,5. Тогда вопрос с первоначально возникшей ошибкой у первого звена (программиста) будет решен с вероятностью 0,125*0,5*0,5=0,03125. Не придирайтесь к цифрам- они нужны как начальная точка для рассуждений. Вот эта вероятность 0,03125- она является мерой того, насколько клиент будет раздражен нашей ошибкой. Здесь 0- клиент в бешенстве, 1- клиент абсолютно доволен. Соответственно, если клиент раздражен, он всем скажет, что программа плохая, никто ее не купит больше и т.д. В общем, 0,03125- это мера успешности компании. Т.е. это то, к чему мы стремимся- успешности компании через производство качественного, радующего покупателей программного продукта. Получается, что, если полученный коэффициент равен 1, то компания успешна, если 0- неуспешна.

Возьмем теперь две крайности. На работу взяли тупого программиста, который не допустит ошибки в программе с вероятностью 0,1. Получается, что вероятность успешности компании, при всех остальных неизменных параметрах равна 0,1*0,5*0,5*0,5*0,5=0,00625.

Другая крайность- талантливый программист с вероятностью недопускания ошибки 0,9. Получается 0,05625. Разница между тупым и талантливым- 11% составила. С одной стороны здорово, но с другой стороны максимум успешности равен 1. А мы за счет таланта программиста добавили в копилку успешности только (0,05625-0,00625)=0,05 единиц, т.е. 5%.

Вы уже сообразили, к чему я клоню? «Догнать» уровень успешности до значений, близких к максимумам, можно, улучшив работу тестировщиков, менеджеров по продажам, технической поддержки. И в совокупности, это позволит нам достичь 0,99 единиц успешности. 0,01- это клиенту «на погоны», ведь он тоже в цепочку включен. В данной формуле успешность определяется самым слабым звеном. Возьмите лучших тестеров, менеджеров, саппорт- по 1 единице вероятности им дайте. Но если будет тупой программист с его 0,1 единицами, то в итоге успешность компании не превысит 0,1.

Какие выводы можно сделать? Компания для повышения вероятности своей успешности должна набирать в штат не только талантливых программистов, но и остальной персонал должен блистать талантами. Только так.

Тривиальный вывод, правда? И как это может помочь нам, программистам, и вообще ITшникам? Первое, что напрашивается, и без этих расчетов- это при трудоустройстве оценивать как с вами кадровики общаются. Ведь в успешной компании все должно быть на высоком уровне. И если вам с порога хамит охранник, игнорирует кадровик, решая свои вопросы и т.д., то наверняка в компании что-то не так. Цепочка бизнес-процессов где-то дает слабину, а, значит, уменьшает вероятность того, что компания окажется успешной.

Однако жизнь куда как заковыристей, чем описанная выше формализованная модель. Программисты знают не один адрес сайта с черными списками работодателей. При этом предприятия из этих списков не разоряются, а очень неплохо себя чувствуют, хотя точно хороших программистов им к себе не заманить. Так как же выживают такие предприятия? Ведь, согласно представленной выше модели, звено «программист» на таком «черносписочном» предприятии получит коэффициент ближе к нулю, а значит и успешность предприятия будет низкая.

Данная модель будет описывать подобные случаи, если ввести коэффициенты значимости для каждого звена. Предлагаю такой вариант формулы: (x+k)/2, где x- вышеописываемые вероятности допускания соответствующими отделами ошибок, k- коэффициент значимости работы отдела для получения конечного результата, т.е. для повышения вероятности успешности компании. Пусть значимость отдела программистов оценивается в 0,5. Тогда, если брать тупых программистов (вероятность НЕ допускания ими ошибки равна 0,1), то значимость качественной работы программистов на конечный результат составит (0,1+0,5)/2=0,3. Соответственно, для талантливых программистов (0,9 вероятность) получаем (0,9+0,5)/2=0,7. Выводы: если работа отдела не сильно сказывается на конечном результате, то таланты не смогут внести существенного вклада в проект, и, соответственно, тупицы тоже особо ничего не испортят. Вот сравните: разница между тупыми и талантами составляет 0,9/0,1=9 раз, а на конечном результате разница видна всего в 0,7/0,3=2,3 раза. Такая ситуация реальна, и часто встречается в «карманных» конторах или предприятиях, стоящих у какой-либо крупной «кормушки». Для таких предприятий важнее не талант программиста, а хорошие менеджеры со связями. Часто внутри таких предприятий атмосфера стоит склочная, начальство прислушивается к менеджерами (ведь они кормильцы предприятия, получается), а те все свои ошибки визгливо валят на программистов, тех в очередной раз называют бездельниками и закручивают гайки (Интернет отбирают, контролируют опоздания и уходы с работы и т.п.).

Итоговая формула получается такая:

,

Где K- вероятность успешности предприятия; i- кол-во отделов, плюс заказчик; k- вероятность безошибочной работы соответствующего отдела; a- коэффициент значимости отдела для компании или, по-другому, насколько вероятно то, что ошибка, допущенная отделом, скажется на конечном результате. Если у нас 5 отделов (см. рисунок 1), то вместе с заказчиком у нас получается 10 переменных с формуле. И только одна переменная, вероятность НЕ допускания ошибки программистом, напрямую зависит от программиста, от его таланта. И чем крупнее предприятие, тем менее заметно влияние таланта программиста на конечный результат компании. Даже в такой простой вышеприведенной схеме талант программиста уже незначителен для конечного результата: предприятие может быть успешным с довольно высокой вероятностью и без талантов, опираясь на «середнячков». Ясно, что любой здравый руководитель предпочтет нанять середнячка и платить ему меньше, чем нанять дорогущего таланта и, практически, не видеть его вклада в конечный продукт (прирост вероятности успешности предприятия будет совсем небольшим, не оправдывающим денег, вложенных в талант).

Теперь можно делать более глобальные выводы, кроме того, что кадровики должны быть с вами обходительны:

1. Чем крупнее компания, тем меньшую значимость для компании будет иметь каждый талантливый программист в отдельности. Для компании, практически с тем же результатом, дешевле будет нанять середнячков, чем талантов. Любой талант в такой компании будет со временем «причесан» под общую гребенку- его способности не будут востребованы и он отупеет до общего уровня.

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

3. «Карманные» и «прикормленные» компании равнодушны к талантам- там их труд практически не сказывается на конечном результате.

Итог: Идеальная компания для программиста- небольшая, с отличными специалистами во всех отделах (вплоть до уборщицы), дружелюбными, профессиональными.

Что же получается тогда? Какая бы ни была компания внешне дружественная к программистам, активно зазывающая к себе, создающая блага, но если компания большая, то предложенная формула приводит нас к печальному выводу: «Талантливому программисту там делать нечего». И, наоборот, внешне непривлекательная небольшая компания может стать настоящей отдушиной для таланта, где он может раскрыться по максимуму.

Остается упомянуть о еще нескольких моментах. Первое, умные большие компании, ощутив на себе «смертельное дыхание» данной формулы, формируют из предприятия холдинг, состоящий из маленьких предприятий, ведущих самостоятельную деятельность. Это неплохо, но часто из управляющей компании холдинга прямо таки веет тупизной, бюрократизмом и предприятия холдинга ощущают это на себе. Периодические набеги руководства холдинга не дают расслабиться, и талантам там все же несколько неуютно. И второй момент, я не учитывал в формуле наличие босса, через которого формируются более сложные связи между отделами.

Оценивая формулу, я вижу, что на ее основе можно развить методологию оценки эффективности деятельности предприятия, притом основанную на количественных показателях деятельности организации. Хммм, вплоть до того, что можно осуществить мечту любого начальника: на экране компьютера кривая, которая в реальном времени показывается эффективность предприятия.

Однако, пора уж закругляться, а то так и до планирования мировой экономики договориться можно!

Путь Microsoft

Начав разговор о Google и неосознанных еще мною причинах привязанности к нему, хочу продолжить тему "человечности" компании с другой стороны. Для этого возьму за основу компанию Microsoft. Шикарная компания: огромный спектр разнообразной производимой продукции (имеется ввиду, что не только ПО они делают), простота осваивания их продукции, распространенность... Да что и говорить, я очень хочу там работать! Но... есть "но" которые портят всю радужность нарисованной картины.

Первая, серьезная для меня, несостыковка с идеологией Microsoft произошла в конце 90х годов. Я тогда был студентом. Написал первую свою программу для печати "платежек" на MS Access 95. Оформил ее, как полагается, для продажи через интернет, сделал страничку, регистрировался где только можно. Программу качали, ею пользовались, и я приступил к написанию ее второй версии. Ох я там и развернулся! Получилась просто "бомбовская" программа. И тут вышел MS Office 2000. Стал я пробовать, запустится ли моя программа под 2000м Access'ом? Нет, не запустилась. Начал копаться с переделками и увидел, что время, затраченное на переделки, превышает время разработки второй версии программы! Да ну в баню, такие дела! Писать, писать программу, чтоб потом ее фактически по-новой переделывать? Несерьезно это. А дальше что? Ну переделаю я в этот раз, они выпустят следующую версию офиса, и опять все по-новой переделывать? Я отказался от дальнейшего развития программы. Затем начал осваивать Visual Basic. На нем программировать было просто, и я был восхищен этим, но опыт с MS Access отложился у меня в мозгу, и я осторожничал с его широким использованием. Недолго я с ним баловался, т.к. компания выпустила .Net, и мои проекты опять стали не компилируемые! Опять куча переделок... Эмоции опустим, просто скажу, что тогда я решил более не связываться с инструментарием для программистов от Microsoft.

Много лет я провел, используя другие компиляторы, никак не соприкасаясь с инструментальным ПО этой компании. Пережил 5-6 переходов между версиями компиляторов, и за все время никогда не испытывал серьезных трудностей (даже и несерьезных практически не было) с переходами.

В последнее время многое изменилось, и я опять начал пробовать инструментарий программиста от Microsoft. Нет, я не собираюсь использовать MFC, WTL- как ни как, а на дворе уже 21 век. Я уже не буду марать свои белоснежные ручки, описывая класс окна, регистрировать его, создавать окно данного класса и прочее- я это делал еще во времена Windows 3.1. Поэтому попробовал .Net... и опять испытал облом в стиле 90х (см. выше). Мое личное мнение- набор классов жутчайший. Как будто его продумывал профессор-теоретик. И глюки... может, это я такой "везучий"? Но, тем не менее, я упорно постигал .Net, насилуя весь свой 15-летний опыт программирования. И вот недавно обратил внимание, что .Net из моей жизни вымыло, и я обосновался опять на ПО не от Microsoft. А я так хотел обучиться технологиям этой компании и устроиться там работать! Карма.

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

1. Прочтите эту новость: Microsoft.com мигрировал на Windows Server 2008. С одной стороны- молодцы, здорово! А с другой стороны? Сколько лет им для этого понадобилось, чтобы разработать наконец таки тривиальный web-сервер (чай не космический корабль!)? Да лет 10, не меньше! И это крупнейшая софтверная компания в мире! Стыд и позор.

2. Послушайте еще вот это: Николай Дударь рассказывает о библиотеках С++. Я обратил внимание на его рассказ о том, как они разрабатывали библиотеку на C++, в то же время делалась новая версия компилятора. Как у них из-за постоянных переделок в компиляторе библиотека постоянно не компилировалась. А почему для компиляции библиотеки они использовали компилятор, который даже не альфа-версия?! Второе, что смутило - слишком молодой парень, чтобы занимать такую ответственную работу. Дело не в возрасте, а в опыте, который приходит только с возрастом. Я считаю, что проекты должны возглавлять люди уровня Веселова и Садовского. Тем более, что речь идет о крупной компании, чья продукция используется миллионами людей.
3. Евангелисты компании проявляют немалую активность, молодцы. Они азартны в продвижении продуктов компании в массы, но не реалисты. Их клич к провайдерам об организации хостингов на платформе Windows я считаю наивным. Почему? Арифметика проста: как они же пишут, такой хостинг будет стоить 20 баксов в месяц. Для сравнения, хостинг, на котором находится этот блог, мне обходится в 5 баксов. К тому же, в этой области много бесплатных или очень дешевых инструментов. Как говорится, "тут рыбы нет". Но у компании есть прекрасный способ добиться увеличения своей доли на рынке инструментов для организации хостинга. Проторенная дорожка- сделать либо весь инструментарий бесплатным, либо выпустить его Express-версию. Уверен, что Microsoft так и поступит в конце концов.
4. Неоднократно в последнее время заманивали пользоваться их messenger'ом. Ну стоит от у меня уж как полгода. До сих пор ни одного контакта. Все мои друзья в аське сидят. И зачем тогда мне нужна эта программа? Притом, реально она не лучше аськи.
5. У меня тут есть еще списочек недоумений по поводу Висты, Офиса и др. Я их оставлю за кадром - итак для флейма в комментариях материала достаточно.
   

И вот теперь, к чему я вел разговор. С одной стороны компания выпускает много всякого ПО, современного и на вид весьма аппетитного. Но с другой стороны от этого ПО исходит некий дискомфорт. Все какое-то нелогичное, словно компания вышивает красивые рюшечки и любуется ими. А больше рюшечки ни для чего и не нужны, кроме как любоваться ими. Так ведь?
По многим направлениям (ОС, ПО для офисной работы, браузеры) компания занимает лидирующие позиции. Программное обеспечение в этих областях развивается уже столь не активно как лет 5-7 назад- S-образная кривая развития явно вышла на верхнее платО. И теперь, чтобы занять чем-то высвободившуюся из этих неактивных проектов ораву программистов, и найти новые источники заработка, компания активно развивает другие направления своей деятельности. Это логично. У компании доля таких уже завоеванных и слабо развивающихся областей (рынков) постепенно увеличивается по отношения к новым или активно развивающимся рынкам. Неактивные, слаборазвивающиеся области характеризуются наличием стандартизации. Соответствие стандартизации требует от компании большей ответственности за свою продукцию. Ведь если есть несколько продуктов, соответствующих стандарту, то преимущество будет на стороне того, кто гарантирует в наибольшей степени соответствие стандарту, а также его дальнейшую поддержку. Таким образом, компания начинает "стареть". На ведущие позиции в компании выходят "старые зубры", которые опытны и "на зубок" знают стандарты, а не молодые и энергичные, которым не хочется, как "книжным червям", копаться в стандартах, а хочется двигать что-то новое, прогрессивное. Именно это и происходит сейчас с Microsoft. Компания находится в стадии перехода от юношества к взрослости. Послушайте, что говорит Веселов, Садовский (ссылки приведены выше). Они говорят об ответственности компании. Все это сопровождается увеличением бюрократии и сменой команд внутри компании (те, кто стоят у истоков компании, уходят).
В итоге "старение" не только Microsoft, но и других крупных игроков завершит бурное развитие рынка информационных технологий. Сейчас мы видим начало этого процесса, а конец мы вряд ли увидим- будем уж все на пенсии, не до этого нам будет. В конечном итоге, во всех областях информационных технологий будут приняты стандарты. Это сделает продажу, настройку и эксплуатацию ПО похожим на эксплуатацию, например, электрических бытовых приборов (фен купил, в розетку воткнул, кнопку нажал - суши волосы). Эту мысль уже не раз озвучивали. Я являюсь ее сторонником, но с поправкой, что это случится еще не скоро.
А что до меня и моей "невезучести" с ПО от Microsoft, то я не сомневаюсь, что как только компания "постареет", так начнет делать уже не рюшечки, а действительно простые, функциональные и удобные программы. Только я до этого времени не доживу.

Это вам "не хухры-мухры"!

Продолжение. Начало "Молоко на губах"

То, что вы могли видеть в фильме "Хакеры"- мелкий детский лепет. Мир IT гораздо интереснее и заковырестее. Как делаются программы? Кем лучше быть- программистом или менеджером? Чтобы понять ответы на эти вопросы прочтите очередную главу этого столь долго затянувшегося приступа графомании.
Попрошу так же учесть, что на практике процесс производства программного обеспечения может весьма сильно отличаться от описанного. Здесь приведен некий средний вариант процесса.

Ранее были рассмотрены различные специализации, и было упомянуто, что у прикладных программистов есть более узкая специализация: разработчик игр, разработчик интерфейсов, разработчик серверных систем и т.д. К тому же, описание специализаций, не привязанных к конкретным должностям, не вписанных в технологическую цепочку производства программного продукта, воспринимается запутанно и мало что проясняет. Поэтому в этой части статьи будет дано описание типовой технологической цепочки производства программного продукта. Наиболее полно данная цепочка реализуется в софтверных компаниях. В отделах АСУ она значительно урезана. Я буду опираться в своем описании на полную, развернутую технологию производства ПО. Бюрократическую сторону (подписание договоров и пр.) производства я буду, по возможности, опускать.
Все начинается с заказа. Это может быть внутренний заказ отделу АСУ, или внешний заказ от клиента, или разработка коробочного продукта. Для больших внешних заказов клиент может провести конкурсные торги. После того, как клиент проявил интерес к предложению от фирмы и готов далее сотрудничать или для коробочной продукции принято решение о целесообразности ее разработки, заказ на разработку передается в IT-отдел, начальнику IT-отдела. Начальник отдела изучает информацию:

• о клиенте,
• о его заказе,
• о приблизительной стоимости проекта "на глаз",
• оценивается "крупность" клиента ("потянет" ли он свои "хотелки", т.е. насколько серьезно его воспринимать),
• о перспективности клиента (насколько вероятно, что в будущем он еще раз обратиться с заказом),
• для коробочной продукции оценивается объем рынка и его динамичность.

На основании этой информации начальник отдела назначает руководителя проекта, обладающего соответствующим опытом, знаниями. С этого момента новый проект начинает свою жизнь, назначенный руководитель проекта несет полную ответственность за выполнение проекта.
Основным документом проекта является техническое задание (ТЗ). Именно оно определяет объем работы, на основании его формируется бюджет проекта, составляется план работ. Любые претензии клиента по проекту будут всегда рассматриваться через призму технического задания, что сделано, что не сделано. Поэтому, если вы, как программист, участвуете в проекте, то никогда не основывайтесь в своих действиях на устной договоренности! В первую очередь, Вас должно волновать выполнение ТЗ, а уж потом все остальное. Составлением ТЗ занимается аналитик. Аналитик вместе с руководителем проекта изучает задачу во всех подробностях и формализует задачу. Если задача по своим масштабам большая или при ее решении есть ряд технологических трудностей, то к составлению ТЗ привлекаются системный архитектор и ведущий программист. Часто их на данном этапе используют для подстраховки, т.е. задача не сложная, но мало ли что – лучше лишний раз переспросить, проконсультироваться, чем потом залатывать прорехи в ТЗ. Системный архитектор подскажет, как лучше решить задачу, сделает примерный набросок архитектуры системы. Результатом его работы будет эскизный проект, обобщенная структурная и функциональная схема программы. Ведущий программист укажет, с помощью каких технологий лучше реализовать предложенную архитектуру проекта, а также подскажет руководителю проекта кто из программистов лучше подойдет для реализации той или иной части проекта. Результатом работы ведущего программиста при составлении ТЗ является частичное техническое задание (ЧТЗ). Техническое задание утверждается начальником отдела и подписывается заказчиком вместе с планом выполнения работ.
После формализации задачи, подписания ТЗ, формирования бюджета проекта руководитель собирает команду, которая будет заниматься реализацией проекта. Для получения людей в свой проект руководитель дает заявку координатору проектов (если в организации нет должности координатора проектов, то начальнику IT-отдела). Координатор оценивает наличие свободных в данный момент программистов или тех, у которых нагрузка по текущим проектам невысокая и утверждает окончательный список команды проекта.
К тому времени руководитель проекта занимается выделением необходимых технических ресурсов для реализации проекта. Возможно, потребуется приобретение дополнительных компьютеров, расширения штата имеющих программистов из-за нехватки имеющихся работников и т.п.
Заявка на приобретение дополнительной техники подается в отдел системного администрирования. Туда же подается заявка на создание необходимых для выполнения проекта сетевых ресурсов (создание рабочей группы в домене, рабочей папки, нового проекта в системе контроля версий и прочее). Старший системный администратор обрабатывает заявку на закупку техники. В соответствии с принятой политикой закупок техники на предприятии по заявке выбирается конкретная конфигурация ЭВМ, добавляется требуемое оборудование для подключения техники к локальной информационной компьютерной сети организации и осуществляется закупка. Системные администраторы осуществляют настройку компьютеров и установку ПО:

• «сетевики» прокладывают локальную сеть.
• Специалисты Help-desk настраивают компьютеры.
• Администраторы сервисов прописывают новые компьютеры в сетевых сервисах, создают под проект сетевые ресурсы.

Если требуется дополнительный найм специалистов, то по заявке руководителя проекта, отдел кадров подает объявление о найме и осуществляет первый, грубый отбор претендентов. Тем, кто только начинает строить свою карьеру это важно знать. Первый контакт с вами будет осуществлять не технический специалист! Тут вам не надо «умничать» про новые технологии и показывать свои глубокие знания. Так как кадровик не технический специалист, то он просто по бумажке проверяет то, что указано ему в заявке на соответствие с тем, что указано в резюме, трудовой книжке, дипломе. Совершенно тупо сравнивается: в заявке на найм есть слово Delphi, в резюме тоже есть слово Delphi – значит, подходит. Также проводится общая ознакомительная беседа. На данном этапе надо быть просто приятным человеком, с которым захотят иметь дело. Затем уже претенденты направляются к руководителю проекта, который проведет с ними техническое интервьюирование. Если в проект уже назначен ведущий программист, то интервьюирование может быть очень подробным – вас погоняют по всему спектру технологий, которые предположительно будут использоваться в проекте. Именно на этом этапе часты письменные задания на месте или даже домашние. Окончательное утверждение кандидатуры осуществляет начальник отдела. Часто это бывает уже третье интервьюирование. Оно общее, не техническое и там надо окончательно урегулировать вопросы зарплаты, режима работы и прочее. Руководитель проекта до этого может вам рассказать о внутренних порядках, о зарплате, но сам он изменить ничего не может. Тут уж все вопросы к начальнику отдела. И, если обоюдное согласие достигнуто, то считайте, что вы приняты.
Итак, у проекта есть руководитель, подготовлена техника, выделены люди, недостающие наняты. В дело вступает системный архитектор. Он уже ранее подключался к проекту при составлении ТЗ. Теперь его задача – плотно курировать проект. По обобщенным структурным и функциональным схемам составляется детализированные структурные и функциональные схемы, которые до мельчайших подробностей обсуждаются с ведущим программистом проекта. Ведущих программистов в проекте может быть несколько. Это делается в том случае, когда проект очень большой и разбивается на части. Реализация каждой части проекта поручается отдельному ведущему программисту. Ведущий программист проекта разбивает проект на отдельные задания и выдает их программистам проекта для написания самостоятельных модулей программы. Выполненные задания сдаются программистами своему ведущему программисту, который осуществляет сборку модулей и компилирует проект в целом (как еще говорят, выкладывает билд проекта).
На основе билда инсталляторы (тоже разновидность узко специализированного программиста) готовят инсталляционный пакет. Пакет попадает на тестирование к тестировщикам. Тестировщики формируют список ошибок с подробным описанием действий, при которых возникла ошибка. Ведущий программист назначает того, кто устранит ошибку (т.к. ведущий программист по описанию ошибки примерно представляет, в каком модуле произошла ошибка, и знает, кто этот модуль делал).
Параллельно работе над программным кодом идет разработка документации по программе, пишутся help-файлы. Этим занимаются "течрайтеры" (tech. writer), т.е. технические писатели в переводе.
В проекте выделяются специалисты по интерфейсу, которые прорабатывают графический интерфейс взаимодействия программы с пользователем. Разрабатываются экранные и печатные формы. Отслеживается, чтобы все формы имели единый стиль.
Код программы, написанный разными программистами, должен быть единообразен, читаем легко, что облегчит в дальнейшем его повторное использование. Для этого код проверяет отдел контроля качества.
Стажерам, как разнорабочим, в проекте поручают выполнение мелкой работы: съездить к заказчику и установить модуль, изменить у заказчика настройки, сбегать к тестировщикам, чтоб они конкретно показали, где у них ошибка "выскочила". Нередко стажерам даже отдельного рабочего места не выделяют.
Постоянно идет согласование работ с заказчиком. По плану ему сдаются промежуточные этапы работ. По ходу реализации проекта производится уточнение и ТЗ может быть скорректировано. Это оформляется дополнительным приложением. По мере продвижения работ программистам часто приходится возвращаться к уже написанным модулям и изменять их либо по требованию заказчика, либо по требованию отдела качества, либо из-за выявленной ошибки при тестировании, либо при решении руководителя проекта, системного архитектора, ведущего программиста изменить что-то в проекте. Часто используется итерационный способ разработки. Это когда в программе реализуется сначала основная функциональность, а потом по мере уточнения требований заказчика и корректировок в проекте выполняются более мелкие проработки в программе.
Чувствуете, как все непросто получается? Программисты, "течрайтеры", интерфейсы, инсталляторы, тестировщики, отдел качества – и все делают работу параллельно, всех их надо вместе свести, состыковать. Вот она, адская работа руководителя проектов! В помощь руководителю проектов разработаны различные методологии проектирования. Однако чаще эти методологии еще больше затрудняют работу. Слишком много вокруг них маркетинговой мишуры. Начинающим выстраивать свою карьеру программистам я рекомендую полностью игнорировать в объявлениях о работе требование знать методологии проектирования RUP и т.п. Если вакансия вам нравиться, а там стоит такой пунктик, и вы не знаете вообще никаких методологий, то все равно смело шлите свое резюме. Скорее всего, сам работодатель за маркетинговой болтовней до конца не понимает и не знает этих методологий. Просто так сейчас модно.
Когда программа закончена, наступает следующий этап- сдача проекта. Заказчику предоставляется финальный релиз программы и, если все выполнено в соответствии с ТЗ и у заказчика нет претензий к исполнению заказа, то подписывается акт выполненных работ. Очень часто на этом этапе заказчик предъявляет множество замечаний и новых "хотелок". Вот тут четкое следование ТЗ играет свою главную роль! Если все выполнено строго по ТЗ, то, как правило, заказчик подписывает акт. В противном случае в дело вступают юристы. Это еще не все! В крупных организациях неповоротливая бюрократическая машина может задержать оплату выполненных работ надолго. Мне известны случаи задержки на 2 года! Все это время руководитель проекта должен держать ситуацию на контроле. Проект только тогда считается законченным, когда по нему будет произведен полный расчет с заказчиком, всем участникам проекта выплачены премии, а дело сдано в архив.
Ну, как? Сложно? Интересно? Вот такая вот она, профессия IT!