Вчера наткнулся на опубликованную в июне в ЖЖ plumqqz заметка “Серебряная пуля есть”. Интересно. Рекомендую к прочтению, мне лично понравилось.
Изложенные в ней соображения хорошо ложатся на мой опыт работы (в частности, в компании “Интервэйл”). У нас вообще команду C++ников называли иногда “государством в государстве” :) Поскольку мы живем жили по своим правилам, работали над своими, практически всегда внутренними проектами, очень часто только под моим единоличным самодурством руководством. Т.е. срабатывала третья составляющая – было одно лицо, которому было это очень нужно. Срабатывала и вторая составляющая – хорошее владение инструментом. Ведь почти во всех наших С++ных проектах используется SObjectizer, а я его не просто знаю – я его разрабатывал ;)
Я бы поспорил лишь с первой составляющей – наличием предыдущей версии разрабатываемого продукта. Имхо, это не так важно. Возможно, необходимо просто четкое понимание того, чего же нужно достичь. В моем случае это было. Поскольку проекты (стадии проектов) стартовали только тогда, когда становилось очевидно что и как. Поэтому первую составляющую в списке я бы оставил, но переформулировал бы. Как-нибудь. Пока не знаю как :)
Update. После написания заметки думал о том, как же переформулировать первый пункт, который звучит: “Необходимо иметь либо работающий макет приложения, который устраивает заказчика, либо глубоко разбираться в предметной области и знать, что же требуется, а еще лучше – и то, и другое.”
Пришел к выводу, что для успеха требуется глубокое знание того, что нужно получить. А оно, знание это, не приобретается просто так, а является следствием опыта. Т.е. если не готовый макет, то хотя бы сколько-то прототипов и загубленных экспериментов в своем багаже иметь нужно. Получается, что первоначальная авторская формулировка точна. И не нуждается в изменении.
8 комментариев:
Да очень хорошо он написал, но это не вся правда :)
Первая составляющая мне кажется не менее важна, по моему прототип очень сильно экономит общее время разработки и ведет к более стройной и красивой архитектуре приложения. Вот для написания прототипа как раз очень важен гибкий высокоуровневый язык. Правда для этого лучше по моему подходят динамические языки а не функциональные.
Думаю, было бы полезно в посте написать чуть подробнее об этой статье (так пост станет понятнее).
1. Статья была подготовлена для журнала о функциональном программировании.
2. Автор формулирует критерии успешного программистского проекта:
"# Необходимо иметь либо работающий макет приложения, который устраивает заказчика, либо глубоко разбираться в предметной области и знать, что же требуется, а еще лучше – и то, и другое.
# Надо хорошо знать инструмент, которым пользуешься – в нем не должно быть никаких темных мест и неожиданных свойств. Он должен быть известен досконально, все его сильные и слабые стороны
# При реализации проекта должно быть одно ответственное лицо, с одной стороны крайне заинтересованное в результате и, с другой, имеющее власть навязать, пусть и административным путем, свое решение, и группа разработчиков, являющихся его активными сторонниками или по крайней мере возможность активного стимулирования таковых."
Кстати, тут первый пункт очень подходяще сформулирован.
@Rustam: с прототипами есть куча проблем. Одна из них (далеко не самая маленькая) - нет времени на его разработку. С московскими заказчиками, например, почти всегда срок сдачи проекта -- вчера.
@san: я специально не стал так делать. Поскольку перечисление критериев у себя практически делает не нужным чтение самой статьи.
Что-то мне подумалось, что эти три пункта можно свести к одному (максимум полутора).
Для успешной реализации прокета нужен человек, который достаточно четко понимает конечную цель, и полностью отвечает/конролирует ее достижение. Тогда он и команду подберет и инструмент найдет/выучит.
Прикол в том, что это должен быть технарь. Т.к. большинство технарей - интраверты, ориентированные на достижение хорошего результата. Менеждеры чаще ориентированы на достижение бонусов лично для себя, поэтому быстро ударяются в политику, т.к. знают, что бонусы гораздо сильнее зависят от должности, а не успешности реализуемого проекта (поэтому, больше внимания уделяют карьере, чем резализации самого проекта). Т.е. дай менеджеру реализовывать проект, он будет его рассматривать как ступеньку для поднятия по карьерной лестнице (что будет с реализацией задачи - второстепенно).
@san: наверное, процент "козлов" среди менеджеров больше, чем среди программистов. Тем не менее, я не думаю, что все менеджеры заинтересованы только в бонусах. По крайней мере у меня перед глазами таких примеров, к счастью, нет.
А по поводу формулировки первого пункта -- я изменил свое мнение и написал update в тексте поста.
@Евгений
Не знаю может мне так везло, но практически все проекты которые начинались без прототипов превращались в конце концов в несопровождаемые заплаточные монстры. Когда был прототип получалось намного лучше, и главное общее время разработки было гораздо меньше практически в разы, просто на прототипе ловятся такие (проектные) ошибки которые потом требуют очень больших затрат на переделки.
@Rustam: я думаю, это не спроста. Ведь даже если копнуть проекты, которые "с первого" раза получались удачно, то наверняка выяснятся две вещи:
- у проекта была внушительная стадия подготовки, на которой удалось проанализировать несколько разных подходов к реализации;
- проект развивался итерационно от простого к сложному с большими рефакторингами в начале каждой итерации. Т.е. версия в конце первой итерации оказывалась как бы прототипом для следующей реализации.
Нужно подчеркнуть, что обе эти вещи обходятся отнюдь не дешево.
Так что без прототипов, действительно, никуда.
Отправить комментарий