пятница, августа 31, 2007

Забудьте все то, чему вас учили...

Прочитал вот здесь - "Программисты – это армия физиков-неудачников". Цитата о вчерашних выпускниках - сегодняшних программистах:

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


Очень точно схвачено. Одно но. Это не про всех. Это про выпускников элитных Московских ВУЗов. Огромному количеству ребят с периферии, приходилось и приходится сейчас значительно труднее пробираться к вершинам карьеры. А потому и отношение к плодам этой карьеры гораздо более теплое :)

среда, августа 29, 2007

Возлюби юзера своего...

«Всякий, возвышающий сам себя, унижен будет, а унижающий себя возвысится»
Евангелие от Луки 18:14.


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

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

Мы, конечно, понимаем, что в конечном итоге получаем зарплату именно из кармана юзера. Поэтому, прежде чем начать писать новую программу, мы собираем у них требования, пишем ТЗ, СИСы, Use Cases и User Stories. Но как часто нам кажется, что в ТЗ написан бред, и мы гораздо лучше понимаем, что на самом деле надо пользователю. А глупый юзер, начинает артачиться и упираться, настаивая на своем. На этот случай у нас есть железный аргумент: «Это сделать не возможно», или по-другому - системные требования и ограничения. Благо, юзер ничего в этом не смыслит, и ему, скрипя зубы, приходится соглашаться на наш правильный дизайн.

Вот так создаются программы, которые никому не нужны.

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

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

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

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

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

пятница, августа 10, 2007

Миссия не выполнима

Есть такой тип программерских команд, я называю их «миссия не выполнима». Что это такое? Начинается все как обычно. Набирается команда для разработки нового проекта. Здесь ключевое слово – «нового». Как обычно в таких случаях, при подборе команды, говорят всякие красивые слова про передовые технологии, невероятную крутость будущего продукта и т.д.и т.п. Хотя это может не иметь ни какого отношения к действительности, не важно. Разработчики, обычно подбираются с уровнем выше среднего, это второй ключевой момент. Есть еще третий ключевой момент, но о нем я скажу несколько позже.

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

Попасть в такую команду очень сложно. «Мы лучшие и нам нужны только лучшие». Новичкам обычно довольно сложно по началу. Когда то мне самому довелось поработать в такой команде, - «Группа разработки ядра» (ядра чего – не скажу :), это было необычайно круто. Я был просто счастлив, что попал туда. Я работал как вол. Потом, спустя время, я был счастлив, что ушел оттуда, это было потом.

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

Стиль управления, предлагаемый методикой экстремального программирования (XP) больше всего подходит в этом случае. Однако XP, согласитесь, требует высочайшей дисциплины в исполнении своих практик. Многие считают, что это не так, и поэтому, в конце концов, все идет кувырком.

Так и выходит, что миссия оказывается не выполнима. Говорят, иногда у них все получается. Говорят, кто-то видел такие команды в Mountain View или в Redmond или высоко в Гималаях. Наша «Группа разработки ядра» была расформирована после трех лет существования. C тех пор прошло три года. На созданном ядре разрабатывается продукт. Разрабатывается до сих пор.

четверг, августа 09, 2007

Лучшее враг хорошего

Если вы владелец собственного сайта или блога, то для вас Google предоставляет замечательный инструмент для анализа посещаемости - Google Analytics. Сервис бесплатный и очень мощный. Можно смотреть общую статистику по посетителям и хитам, можно анализировать источники переходов, популярность содержимого и многое другое. Одни словом - замечательный сервис.
Пару месяцев назад Google решил сделать его еще лучше и выпустил новую версию. Старая версия Google Analytics перестала работать 18 июля.
Проблема в том, что меня вполне устраивала старая версия. Возможностей там было намного больше, чем мне надо. А вот новый интерфейс мне активно не нравится. Он гораздо сложнее и более навороченый.
Каков результат? Я практически перестал пользоваться этим сервисом. Блог у меня не коммерческий и статистику я мсотрю только для интереса. А что за интерес копаться в интерфейсе который тебе не нравится...
Теперь больше пользуюсь сервисом FeedBurner Stats. Кстати, сегодня впервые число подписчиков блога на FeedBurner впервые перевалило за 100. Спасибо всем.

Процесс документирования и документирование процесса.

Надо ли писать документы в процессе разработки, зачем и как много? Это тема одного из вечных программерских холиваров.

В 1992 году я с приятелем начал разрабатывать программу для одной конторы,
занимавшейся обменом квартир. Если кто помнит, тогда почти все квартиры были государственными (кроме кооперативов и частных домов) и их не продавали и покупали, а меняли. Причем схемы обмена бывали порой весьма замысловатыми. Тогда это был бизнес. А для нас это был первый «коммерческий проект». Естественно ни о какой документации речи тогда не шло. О документации мы вообще ничего не знали. Нет, конечно, мы были в курсе, что все инженерные системы, да и программные тоже, имеют пухлые альбомы фиолетовой документации отвратительного качества, размноженные на светокопии. Мы даже читали замечательную документацию пакета Borland Turbo Vision (кстати, это был действительно выдающийся документ, который привил мне правила хорошего тона кодирования на всю оставшуюся жизнь). Но то была пользовательская документация. О документации процесса разработки мы тогда просто не думали (впрочем, как и о многих других вещах). У меня на руках была собственноручно написанная оконная GUI библиотека для CRT режима, которую просто необходимо было опробовать на каком ни будь приложении, а у моего приятеля был заказчик, которому была нужна программа для его бизнеса по обмену квартир.

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

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

Я думаю, это достаточно типичная картина для времен становления индустрии коммерческой разработки ПО. Нет, я конечно, понимаю, что уже в те времена существовали и IBM, и министерство обороны США, где эти процессы были на очень высоком уровне. И книге Брукса «Мифический человеко-месяц» в тот год исполнилось 17 лет. Но то было время, когда в бурно развивающуюся у нас отрасль коммерческой разработки ПО, люди приходили весьма замысловатыми путями, и каждый учился на собственных ошибках. В последующие годы, работая во многих местах, мне часто приходилось писать код по требованиями, пересказанным устно через третьи руки. Потом этот код многократно переписывался и правился, пока не достигал нужной кондиции. Это конечно напрягало. Для многих программистов несбыточной мечтой было писать код по Техническому заданию (ТЗ).

Время шло, индустрия развивалась. Все большее число людей начинало понимать, что ТЗ это очень удобная штука не только для написания кода, но и при сдаче программы заказчику. Повсеместно появлялись различные ТЗ, ТП, ПТ и прочая документация. Устраиваясь на работу, программист спрашивал: «Вы пишете по ТЗ?», и ему все чаще отвечали «Да». Часто толку от этого бывало чуть, а сами ТЗ составлялись по следам уже написанного кода (для этого даже термин есть - reverse engineering).
Но тут неожиданно выяснилось, что вполне можно успешно разрабатывать софт и без обильной документации. На сцену вышел Кент Бек и компания со своим Экстремальным программированием (XP). Все это выглядело как грандиозное надувательство. Однако на деле оказалось, что действительно, используя совокупность продвинутых инженерных и социальных практик можно создавать программы, за которые заказчик не набьет тебе лицо, и при этом не особо заморачиваться документированием процесса.

С тех пор и повелось, что при обилии документации мы ворчим, что нам не когда писать код, а при ее отсутствии, что наш код работает не так потому, что нигде не написано, как он должен работать. Что лучше, расписывать все до последней кнопки на экране и до последнего условия в алгоритме проверки счета, и бесконечно согласовывать эти документы, или всякий раз идти и спрашивать об этом заказчика? На этот вопрос ответа нет.

Сейчас я работаю в организации, которая сертифицирована на CMMI 5 уровня. У нас определено 148 типов(!) различных документов, которые используются в процессе разработки. Помимо этого, существует так называемый “process tailoring” - индивидуальная подгонка процесса разработки под конкретный проект, когда мы можем сказать, какие конкретно документы будут использованы в проекте, а какие нет. И тем не менее, компания активно использует различные варианты Agile методологий во многих проектах. Так что же лучше - сквозное и подробное документирование, или гибкость и разработка непосредственно по запросам заказчика?

Как всегда, «истина где-то рядом». К сожалению, хорошо документированные проекты проваливаются ничуть не хуже, чем вовсе не документированные, но очень гибкие. Если бы сквозное и подробное документирование всего и вся от требований до планов и результатов тестирования было серебряной пулей, которая спасает проекты от краха, то тогда, наверное, не расцветали бы махровым цветом различные Agile методики разработки. Подробное документирование многократно увеличивает затраты и время разработки, и совершенно трагическим образом удорожает ее. Специалисты, которые создают основные документальные артефакты – аналитики, архитекторы, менеджеры проектов, стоят не в пример дороже программистов, а вот качество их работы оценить бывает очень трудно. Разрушительный эффект, который способен произвести на проект плохой архитектор или аналитик бывает просто поразительным.

У Agile свои проблемы. Когда через квартал после сдачи проекта, разъяренный пользователь пытается выяснить «почему этот отчет не учитывает те суммы» - никто не может ему ответить. Степень удовлетворенности заказчика зачастую страдает из–за того, что невозможно отследить изменения требований, а порой и сам факт того, что требования реализованы должным образом. И копание в бэклогах проекта (если они есть) обычно мало помогает.

Документация конечно нужна. Вопрос – в каком количестве и какого качества. Факторов, влияющих на то, сколько и каких документов вам потребуется, огромное количество, это:
• Специфика предметной области проекта
• Специфика продукта: внутренний, внешний, или коробочный продукт
• Специфика заказчика и даже отношений с ним
• Специфика инструментов разработки и архитектуры системы
• Квалификация разработчиков и других членов проектной команды
• Сроки и продолжительность проекта
• Кто и как будет осуществлять развертывание и поддержку продукта.

Однозначно не стоит писать документы, которые не будет читать никто кроме автора (если конечно от этого не зависит ваша проектная премия :). Не стоит писать документы, которые дублируют исходный код программы, если только вы не передаете впоследствии программу на поддержку другой команде. Многостраничные use case часто могут заменить простые прототипы, а архитектурные описания – диаграммы компонент и классов. Но тут надо быть осторожным. Все зависит от специфики предметной области и квалификации разработчиков.

В общем, вам решать – каким будет процесс документирования и документирование процесса.

пятница, августа 03, 2007

Кумулятивный принцип разработки софта

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

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

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

С превращением требований в дизайн приложения дела обстоят хуже всего. Например, последователи Кента Бека эту часть разработки софта вообще не признают. Их принцип – садись и кодируй, дизайн возникнет сам по себе, а когда он возникнет - мы его отрефакторим. Другие подходят к проблеме во всеоружии OOP, OOD, SOA, c арсеналом паттернов, всегда имея наготове принцип Лискоу, или другой убойный инструмент для монтажа правильного дизайна. Для многих это процесс сродни шаманству, то что требования определяют дизайн – это понятно, он вот каким образом??! Ну а для менеджера есть только две архитектуры: правильная и неправильная. Правильна – та, которая позволяет за выделенные деньги получить хоть как-то работающее приложение. Все остальные - неправильные. И надо признать, что именно они ближе всего к истине.

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

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

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

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

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