Баланс между скоростью разработки и внедрения и качеством. Мнения

← →
data © (2007-11-30 12:42) [0]

Вчера копаясь в исходниках верхнего уровня (не сишном коде, а неких макросах) проекта, с которым сейчас работаю, нашла много неоптимального (не то, чтоб неправильно, но противновато реализовано), зачесались руки переделать. Те, кто работали с этим до меня, объясняют происхождение таких "нехороших" мест спешкой при реализации и внедрении: типа была ситуация из серии "завтра уже надо, чтоб было", некогда было посидеть, продумать и пр.. поэтому встречается копипейст, неоптимальный sql и тп. Сама я уже не первый раз работаю вот с таким "скороспелым" проектом. За 3 года до этого работала главным разработчиком проекта, реализованного в таком же режиме, и даже не внутрикорпоративного, как сейчас, а коробочного коммерческого продукта. Там было еще круче - "ребята, давайте срочно, тк это мы уже продали и получили деньги". И что странно: оба этих проекта вполне успешны - внедрены, хорошо работают. Коммерческий продается, идет в регионы и заграницу, внутрикорпоративный тоже пашет будь здоров, каждому бы так, вобщем, процветают, несмотря на плоховатый код.
В тоже время работала в команде и с таким проектом, где было сколько угодно времени на "продумать", "придумать", "построить правильное дерево наследования классов", "довести до блеска" и тп. Проект оказался провальным - все время срывались сроки, исходники превратились в слишком красивые, обобщенные и универсальные... вобщем такой код ради кода. Проект при мне так и не был внедрен и не внедрен до сих пор, насколько я знаю.
Хотелось послушать мнения опытных людей по сабжу: в чем тут дело? Успех первых двух проектов и неуспех второго только из-за менеджемента? Ведь разработчики во втором всреднем на голову, а то и на две выше, чем в первых.
Кто как находит баланс между хорошим кодом и быстрым и успешным внедрением? Насколько это связано?
Или я вообще не там причины вижу?

← →
Jeer © (2007-11-30 12:46) [1]

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

← →
boriskb © (2007-11-30 12:46) [2]

> Насколько это связано?

Очень слабо.
В исключительных случаях.

← →
alex_*** © (2007-11-30 12:49) [3]

я так думаю...
программистам надо программировать, манагерам продавать. Дай волю программистам, они бы вообще писали код ради кода. Утрирую конечно. Сильные манагеры+плохие программисты - 1 вариант, наоборот - 2-й. Лучший вариант - баланс.

← →
TohaNik © (2007-11-30 12:50) [4]

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

Наверняка был не очень нужен, иначе "завтра уже надо, чтоб было".

← →
data © (2007-11-30 12:51) [5]

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

правильно ли я понимаю суть термина "спиральный" - это сначала сделать все по-простому и выйти на рынок, потом уже заниматься улучшением и оптимизацией, учитывая опыт внедрения и мнения уже поработавших пользователей?

← →
alex_*** © (2007-11-30 12:52) [6]

ну и еще если человек умеет писать хороший код это не значит что он умеет делать проекты по ТЗ и в срок.

← →
alex_*** © (2007-11-30 12:54) [7]

> нашла много неоптимального (не то, чтоб неправильно, но
> противновато реализовано), зачесались руки переделать.

а вообще надо переделывать только критичные по производительности куски или те которые планируется развивать.

← →
data © (2007-11-30 12:55) [8]

> Сильные манагеры+плохие программисты

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

← →
data © (2007-11-30 12:57) [9]

> а вообще надо переделывать только критичные по производительности
> куски или те которые планируется развивать.

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

← →
data © (2007-11-30 13:00) [10]

> Наверняка был не очень нужен, иначе "завтра уже надо, чтоб
> было".

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

← →
Anatoly Podgoretsky © (2007-11-30 13:06) [11]

> data (30.11.2007 12:42:00) [0]

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

← →
Anatoly Podgoretsky © (2007-11-30 13:07) [12]

> data (30.11.2007 12:51:05) [5]

> сначала сделать все по-простому и выйти на рынок, потом уже заниматься улучшением и оптимизацией

А можно и не заниматься, продукт то продается.

← →
data © (2007-11-30 13:08) [13]

> Anatoly Podgoretsky © (30.11.07 13:06) [11]

так в итоге это хорошо или плохо? получается так и надо работать для упеха проекта?

← →
Anatoly Podgoretsky © (2007-11-30 13:11) [14]

> data (30.11.2007 13:08:13) [13]

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

← →
clickmaker © (2007-11-30 13:15) [15]

> [13] data © (30.11.07 13:08)

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

← →
Jeer © (2007-11-30 14:49) [16]

> data © (30.11.07 12:51) [5]
>
> правильно ли я понимаю суть термина "спиральный" - это сначала
> сделать все по-простому и выйти на рынок, потом уже заниматься
> улучшением и оптимизацией, учитывая опыт внедрения и мнения
> уже поработавших пользователей?

Вы совершенно правильно поняли и, как говорится, лучший тестировщик - это пользователь:))

Поскольку я давно работаю в одиночку, этот метод для меня стал основным.
Пару-тройку лет назад ко мне подошли из вет.инспекции и попросили сделать небольшую программку для надпечатывания документов строгой отчетности - вет.свидетельств.
Слегка вникнув в прикладную область, я почти сразу понял, что вырисовывается неплохой проект в масштабах области.
Но первая версия делала почти только то, что и просили - надпечатка + элементы учета. Дальше - продукт стал себя продавать сам.
Вот это самое "почти" и оказалось "калачом" для Заказчика.
В итоге за пару лет состоялись 3-4 принципиально отличающиеся по сложности версии: привыкли пользователи, начальство и клиенты.
Я же получил в "вечное" пользование эту нишу.

"За скромные тугрики" (С)

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

← →
data © (2007-11-30 16:06) [17]

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

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

> Главное, он должен быть расширяемым. Чтобы не было такого,
> что при добавлении одного поля в отчет требовалось перелопатить
> кучу запросов, формочек и т.п.

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

А где бы почитать про руководство проектами, про подходы и прочее? может кто знает и порекомендует хорошую лит-ру.

← →
clickmaker © (2007-11-30 16:46) [18]

> [17] data © (30.11.07 16:06)

ну я к тому, что если проект не "для дома, для семьи", то желательно сразу закладываться на то, что он может расширяться. Что клиент может новые фишки захотеть и все такое прочее.
Работал как-то на проекте, где было множество сущностей предметной области, каждая со своими фишками, свойствами и т.д. И обрабатывались они все по своему, практически не пересекаясь. Все работало прекрасно. Но в один прекрасный день, для цЕлей администрирования понадобилось работать с ними единообразно, независимо от назначения. Вот тут-то и началось...
А если бы изначально проектировали как набор классов-набор объектов, то не пришлось бы заниматься тупым рефакторингом

← →
tesseract © (2007-11-30 16:49) [19]

> ну я к тому, что если проект не "для дома, для семьи", то
> желательно сразу закладываться на то, что он может расширяться.
> Что клиент может новые фишки захотеть и все такое прочее.
>

Главная проблема при составлении ТЗ - добиться от клиента всех мелочей. Что-бы не было потом "а у меня так было, я думал так и будет!". или "я думал, это подразумеваеться"

← →
data © (2007-11-30 16:52) [20]

> Главная проблема при составлении ТЗ - добиться от клиента
> всех мелочей. Что-бы не было потом "а у меня так было,
> я думал так и будет!". или "я думал, это подразумеваеться"

на это есть целая теория управления требованиями...

← →
clickmaker © (2007-11-30 16:53) [21]

> [19] tesseract © (30.11.07 16:49)

главное, осознать, что клиент хочет как можно меньше делать движений мышкой и стучать по клаве )
Однако, при этом, если клиент лажает, то виноват программист, который не вывел миллион предупреждений "а вы уверены, что хотите...?" )

← →
data © (2007-11-30 16:54) [22]

> Однако, при этом, если клиент лажает,

вообще-то клиент всегда прав. Скорее всего, лажает аналитик :)

← →
Ricko © (2007-11-30 17:18) [23]

Странное совпадение: http://rizhikov.habrahabr.ru/blog/31706.html

> вообще-то клиент всегда прав. Скорее всего, лажает аналитик
> :)

Не ту мышку санализировал ?

> Не ту мышку санализировал ?

может и так - смотря какой проект :)

> Ricko © (30.11.07 17:18) [23]

спасибо за ссылку, статья неплохая. А где совпадение?

> правильно ли я понимаю суть термина «спиральный»

Нет, см. Unified Process

> [26] Kolan © (30.11.07 17:39)
> > правильно ли я понимаю суть термина «спиральный»
>
> Нет, см. Unified Process

сначала клиенту отдают форму с одной кнопкой и полем ввода. Спрашивают: "Размер устраивает? А цвет?"
Если да, то добавляют DBGrid, к примеру. Если нет, возврат на шаг 1, меняют цвет/размер кнопки/формы и опять несут клиенту.
И т.д.
Вот что такое RUP вкратце )

> Вот что такое RUP вкратце )

Я понял что лол, клиенту там ниче не отдают, ему просто часто показывают результаты, но отдавать недоделано и ждать пока он протестит на ранних этапах  такого нет, тем более на рынок выкидывать&#133

> [28] Kolan © (30.11.07 18:11)
> > Вот что такое RUP вкратце )
>
> Я понял что лол, клиенту там ниче не отдают

ну это само собой. Чего он будет с одной кнопкой делать?

← →
Черный Шаман (2007-11-30 20:03) [30]

> data © (30.11.07 12:42)

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

← →
Черный Шаман (2007-11-30 20:16) [31]

> clickmaker © (30.11.07 16:46) [18]
> Работал как-то на проекте, где было множество сущностей
> предметной области, каждая со своими фишками, свойствами
> и т.д. И обрабатывались они все по своему, практически не
> пересекаясь. Все работало прекрасно. Но в один прекрасный
> день, для цЕлей администрирования понадобилось работать
> с ними единообразно, независимо от назначения. Вот тут-то
> и началось...
> А если бы изначально проектировали как набор классов-набор
> объектов, то не пришлось бы заниматься тупым рефакторингом

Ну и что? Вот купили вы мерседес, ездите, все вам завидуют, но вот вам понадобилось кирпичи на дачу возить - что проще, переделать мерседес или купить камаз(или даже нанять фирму для перевозки кирпичей).

Так и с проектом - вот вложили вы деньги в программный продукт, работаете отбили уже деньги в 10 раз. Если вам нужна новая функциональность - просто начинаете новый проект с частичным использованием кода из старого. Данная бизнес-модель поддерживается всеми крупнейшими IT-компаниями мира.

На самом деле от менеджмента зависит не много. От менеджмента зависит все. Даже если продукт востребован и идеально написан, совсем не факт, что он станет лидером. Пример OS/2 против Win95 очень показателен. Суть в том что первая версия не обязана быть вылизана. Напротив, она должна содержать недостатки, но два фактора обязательны - она должна быть стабильна и должна удовлетворять большинство потребностей пользователя, причем на хорошем уровне эргономики. Тогда ее можно энергично PR-ить на рынке и получить быструю окупаемость и прибыль. Добавлять функционал и скорость можно и нужно постепенно.

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

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

> Сергей Суровцев © (30.11.07 20:22) [32]
+1
хотя не всегда применимо 100%, вернее, неприменимо 100%
но суть, пусть утрированная - в самое оно

Баланс между скоростью разработки и внедрения и качеством. Мнения Найти похожие ветки