Здравствуйте, Flamer, Вы писали:

F>Здравствуйте, Equilibrium, Вы писали:

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

E>>Или значит то, что продукт хорошо сделан, и что заказчик на всех этапах формулировал требования предельно чётко.

F>Вы сами-то в это верите? Не бывает такого просто потому, что такого не может быть.

Так должно быть и часто бывает. Это и называется "ПРОФЕССИОНАЛИЗМ".

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

Если Заказчик не может сформулировать требования четко, то помогите ему в этом, подсказав и показав на примерах различные варианты реализации его идей (можно, например, быстро набросать и показать несколько различных макетов будущего продукта) — и пусть он выбирает. Это очень важно.

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

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

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

И удачный результат бывает не так уж редко.

Здравствуйте, SMSM, Вы писали:

SMS>Здравствуйте, Flamer, Вы писали:

F>>Здравствуйте, Equilibrium, Вы писали:

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

E>>>Или значит то, что продукт хорошо сделан, и что заказчик на всех этапах формулировал требования предельно чётко.

F>>Вы сами-то в это верите? Не бывает такого просто потому, что такого не может быть.

SMS>Так должно быть и часто бывает. Это и называется "ПРОФЕССИОНАЛИЗМ".

При чем тут ПРОФЕССИОНАЛИЗМ?
А для кого тогда инкрементные/итеративные модели жизненных циклов придумали
в которых предполагается, что требования будут меняться и добавляться
по многу раз за время жизни продукта.

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

А если ты разрабатываешь, к примеру, новый Word, то настоящий отклик пойдет только
после первого релиза...

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

Здравствуйте, SMSM, Вы писали:

[]
B>>>>А капризы длятся ровно столько, сколько продукт вообще нужен.
B>>>>Нету "каприз", значит никому продукт не нужен.

E>>>Или значит то, что продукт хорошо сделан, и что заказчик на всех этапах формулировал требования предельно чётко.

F>>Вы сами-то в это верите? Не бывает такого просто потому, что такого не может быть.

SMS>Так должно быть и часто бывает. Это и называется "ПРОФЕССИОНАЛИЗМ".

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

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

SMS>Если Заказчик не может сформулировать требования четко, то помогите ему в этом, подсказав и показав на примерах различные варианты реализации его идей (можно, например, быстро набросать и показать несколько различных макетов будущего продукта) — и пусть он выбирает. Это очень важно.

Заказчик по определению не умеет формулировать требования четко. Помочь ему в этом — это значит лишь немного прояснить для себя ситуацию, выяснив у заказчика непонятные вам стороны. Это нисколько не влияет на уменьшение количества "капризов".

SMS>Именно так и появляются продукты, при эксплуатации которых не возникает существенных "капризов".

Так, давайте котлеты отдельно а мухи в суп, ок? Существенный "каприз" и "каприз" — две большие разницы. К тому-же, в моей практике не было (и не будет, я знаю) такой ситуации, когда заказчик после получения первой версии продукта, сделанной по его требованиям, был удовлетворен. Удивительно, но вы знаете, что заказчик, получив готовую первую версию, видит продукт целиком и у него открывается второе дыхание — он понимает, что вот здесь было бы лучше еще и вот это сделать и пр. и пр.

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

Мы говорим о "капризах", или опять теорию разводим? Ежу ясно, если заказчик сказал, что программа должна копировать в буфер обмена, но она не копирует — это косяк выполнения заказа. Капризы заказчика каким боком здесь?

SMS>Разумный разработчик консультирует Заказчика,аналитиков и менеджеров, участвует в согласованиях проекта и добивается того, чтобы будущий продукт был качественным, чтобы не было грубых ошибок и недостатков в ТЗ и постановках, чтобы возможные будущие доделки были сведены к минимуму.

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

Здравствуйте, Equilibrium, Вы писали:

GUI>>2) Рано или поздно вас перестаунут брать на работу, поскольку работодатели, как Вы сами верно сказали, хотят стабильных сотрудников. И когда они видят в резюме, что вы нигда не работали больше 6-10 месяцев просто перестанут Вас брать на работу на этом основании.


E>Средний период из "полгода-полтора года" — год. Это нормально. Нижней границы лучше пока не придерживаться, потому что работодатели ещё не готовы воспринимать это нормально. Их надо подготовить к этому постепенно.

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

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

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

Здравствуйте, Equilibrium, Вы писали:

Мне кажется с возрастом это пройдет

Здравствуйте, bkat, Вы писали:

B>Здравствуйте, SMSM, Вы писали:

SMS>>Здравствуйте, Flamer, Вы писали:

F>>>Здравствуйте, Equilibrium, Вы писали:

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

E>>>>Или значит то, что продукт хорошо сделан, и что заказчик на всех этапах формулировал требования предельно чётко.

F>>>Вы сами-то в это верите? Не бывает такого просто потому, что такого не может быть.

SMS>>Так должно быть и часто бывает. Это и называется "ПРОФЕССИОНАЛИЗМ".

B>При чем тут ПРОФЕССИОНАЛИЗМ?

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

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

B>А для кого тогда инкрементные/итеративные модели жизненных циклов придумали
B>в которых предполагается, что требования будут меняться и добавляться
B>по многу раз за время жизни продукта.

Итеративные модели жизненных циклов действительно имеют ввиду отслеживание времени жизни продукта. Но к нашей дискуссии это имеет мало отношения, так как нормальная работа строится по принципу:
1) Делаешь законченный вариант продукта (1 версию)
2) Она выпускается в продажу и живет некоторое время самостоятельно
3) Команда ведет поддержку продукта, мелкие добавления и исправления ошибок
4) Все созданные при разработке материалы систематизируются и готовятся так, чтобы их могла принять другая команда (т.е. составляется
документация, комментируются и канонизируются (уппрощаются) коды и т.п.
5) Команда завершает работу над проектом

и только далее:
6) Группа поддержки, менеджеры и аналитики собирают и систематизируют замечания от потребителей по текущей версии
7) Принимается решение о изготовлении версии 2 и ее возможностях
8) Создается команда и делается версия 2

и т.д.

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

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

Но в дискуссии речь шла о другом: когда разработчик морально вправе покинуть команду без ущерба для репутации и квалификации?.

Так вот мой ответ: на этапе 5. Т.е. сделанная версия должна быть полностью передана потребителям для работы и Заказчику для поддержки.

Кроме того, я считаю, что при грамотно проведенной предварительной работе команды (менеджеров, аналитиков и консультирующих их программистов) нормальной ситуацией является то, что ни требования, ни технический проект, ни архитектура софта во время разработки на этапах 1-5 не меняются,причем не по чьей-то воле, а потому что нет необходимости их менять (все предусмотрено).
Сам имею достаточно большой опыт подобной работы и как разработчик, и как руководитель команды.

B>То, что ты описал, возможно только если есть явный заказчик,
B>который уже почти представляет, что надо делать.
B>К примеру если Нокиа отдаст часть работ питерской фирме,
B>то питерская фирма видимо будет иметь дело с хорошо определенными,
B>редко и не сильно меняющимися требованиями на одной итерации...

Так здесь и идет речь об одной итерации.
Но если Вы получили требоваиня, например, от Nokia, то никто не мешает Вам их обдумать, проверить, приложить к себе, понять, имеют ли они некоторую законченную для версии форму. И если не имеют, то никто не мешает Вам сформулировать свое видение вопроса и предложить его Заказчику.
Конечно, решать в любом случае будет он, но предупредить его о последствиях тех или иных решений, на которые он, возможно, не обращал внимание, дополнить его видение вопроса до большей законченности — это прямая обязанность команды (если она заинтересована в результате, а не просто в получении от него денег). Разумные предложения западные Заказчики (и Nokia в частности) обычно принимают — нужно только грамотно все разъяснить, если потребуется — на примерах и макетах.

B>А если ты разрабатываешь, к примеру, новый Word, то настоящий отклик пойдет только
B>после первого релиза...

Так о первом релизе и идет речь — как о результате деятельности команды. Разработка того, что войдет во второй релиз — это работа команды N 2 (часто той же самой). Важно, чтобы работа над ошибками в релизе 1 была сведена к минимуму.

Когда же готовишь релиз 1 продукта, то нужно (и это возможно) формулировать так ТЗ и постановки, чтобы он:
— имел законченный вид
— имел свою нишу на рынке и в чем-то был удобнее конкурентов (если речь о тиражируемых продуктах).
— чтобы острой необходимости в переделках сделанного не было.(т.е. тех переделках, без которых продажа продукта на рынке невозможна).

B>В общем если контора продвинута, то разработчики скорей всего действительно имеют
B>дело с четкими требованиями, но они гарантированно будут меняться/добавляться
B>в ходе жизни продукта. Речь идет именно об этом...

Разработчиков, имеющих дело с заранее четко определенными требованиями Заказчика я не встречал. Но в нормаьлных командах после грамотно проведенной предварительной работы всей команды (менеджеров, аналитиков, консультантов-программистов, обсуждений с Заказчиком) вырабатываются действительно четкие требования к релизу продукта, что позволяет успешно решать этапы 1 — 5.

Здравствуйте, Flamer, Вы писали:

F>Здравствуйте, SMSM, Вы писали:

F>[]
B>>>>>А капризы длятся ровно столько, сколько продукт вообще нужен.
B>>>>>Нету "каприз", значит никому продукт не нужен.

E>>>>Или значит то, что продукт хорошо сделан, и что заказчик на всех этапах формулировал требования предельно чётко.

F>>>Вы сами-то в это верите? Не бывает такого просто потому, что такого не может быть.

SMS>>Так должно быть и часто бывает. Это и называется "ПРОФЕССИОНАЛИЗМ".

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

F>Еща раз повторяю — профессионализм здесь не при чем. И я не мажу всех одной краской, как вы выразились. Я просто знаю, что нет на свете такого заказчика, который был бы сразу доволен всем. То есть пресловутые "капризы" будут всегда, будь вы хоть семи пядей во лбу профессиональным разработчиком. От вас это не зависит. Об этом и речь. Если прочитать подоплеку того, на что я отвечал, повнимательнее, то сразу становится понятно, о чем я писал.

Я считаю, что не в последнюю очередь это зависит именно от НАС. Если формулировать задачу нормально и работать вместе с Заказчиком вместе (а не ждать от него ЦУ), то, когда будет идти разработка, серьезных "капризов" (меняющих архитектуру, перечеркивающих сделанную работу) не будет — просто потому, что для этого не будет почвы (см. мой ответ по соседней ветке)

SMS>>Если Заказчик не может сформулировать требования четко, то помогите ему в этом, подсказав и показав на примерах различные варианты реализации его идей (можно, например, быстро набросать и показать несколько различных макетов будущего продукта) — и пусть он выбирает. Это очень важно.

F>Заказчик по определению не умеет формулировать требования четко. Помочь ему в этом — это значит лишь немного прояснить для себя ситуацию, выяснив у заказчика непонятные вам стороны. Это нисколько не влияет на уменьшение количества "капризов".

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

SMS>>Именно так и появляются продукты, при эксплуатации которых не возникает существенных "капризов".

F>Так, давайте котлеты отдельно а мухи в суп, ок? Существенный "каприз" и "каприз" — две большие разницы. К тому-же, в моей практике не было (и не будет, я знаю) такой ситуации, когда заказчик после получения первой версии продукта, сделанной по его требованиям, был удовлетворен. Удивительно, но вы знаете, что заказчик, получив готовую первую версию, видит продукт целиком и у него открывается второе дыхание — он понимает, что вот здесь было бы лучше еще и вот это сделать и пр. и пр.

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

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

F>Мы говорим о "капризах", или опять теорию разводим? Ежу ясно, если заказчик сказал, что программа должна копировать в буфер обмена, но она не копирует — это косяк выполнения заказа. Капризы заказчика каким боком здесь?

Если есть нарушение согласованной спецификации — то это однозначно ошибка и проблемы разработчика. Здесь я их не обсуждал. Я говорил об идеологических ошибках.
Если использовать Ваш пример, то, например, явно удобнее переносить данные через буфер копирования, а в спецификации сказано, что перенос только через текстовые файлы. Вы реализовываете как в спецификации. Заказчик получает программу и пробует скопировать, как в других программах Windows. Ему неудобно и возникает "каприз", который легко можно было бы избежать при грамотной предварительной работе команды над спецификацией.

SMS>>Разумный разработчик консультирует Заказчика,аналитиков и менеджеров, участвует в согласованиях проекта и добивается того, чтобы будущий продукт был качественным, чтобы не было грубых ошибок и недостатков в ТЗ и постановках, чтобы возможные будущие доделки были сведены к минимуму.

F>Скажите, с какой книжки вы это все списали? Прямо хоть на стенку вешай Разумный разработчик разрабатывает. Нет, он учавствует в обсуждениях, добивается того, чтобы его мнение было учтено и пр. по мелочам. Но, например, его мнение на дизайн программных компонентов может не совпадать с мнением тимлидера — а это все, приплыли .
F>По правильному существуют специально обученные люди — проджект-менеджеры, которые как раз тем и занимаются, что добиваются от заказчика того, чего ему нужно, спуская это вниз на разработку.

Не путайте право принятия решения по, например, дизайну(им обладает team leader и люди в команде,отвечающие за дизайн) с консультативной помощью. Если разработчик видит, что дизайн задуман некачественный, то он ОБЯЗАН изложить свое видение вопроса в команде, а не держать его себе в тряпочку. Остальное — вопрос дискуссии и отношений внутри команды.
В хороших командах, которые действительно добиваются результатов, разумные предложения в основном принимаются. Нужно только излагать не абстрактные мысли "по поводу", а давать четкие аргументы и показывать законченную картину того, что получится, в случае принятия тех или иных решений.
Любой хороший team leader знает, что все люди ошибаются — и дизайнеры с аналитиками тоже (даже самые опытные). Потому он должен быть открыт для конструктивных замечаний. Обычно или вырабатывается новое устраивающее всех решение, либо team leader-у или дизайнеру удается убедить разработчика в правильности подхода, который изложен в спецификации.
Если же разработчик категорически не согласен с тем, что реализуется командой, то у него всегда есть право голосовать ногами (уйти из команды).
Хороший team leader знает, что если у него в команде работают разработчики, которые категорически не принимают тот результат, который должна дать команда, то толку не будет. Поэтому в таких случаях часто разработчики выводятся из команды.
Но если разработчик остается в команде (по тем или иным причинам), то он и должен отвечать за результат наравне с остальными ее членами, активно помогая друг другу, а не разбегаясь по огородам (и что не в моем огороде — то хоть там трава не расти). Именно в этом залог успеха команды. При этом, естественно, основная работа программиста — разрабатывать, дизайнера — делать дизайн, аналитика — писать постановки и т.п. Но все они должны работать в одной КОМАНДЕ.
Я не понимаю программистов, которые после провала проекта говорят "НО Я НИ В ЧЕМ НЕ ВИНОВАТ — Я ДЕЛАЛ ВСЕ, КАК ГОВОРИЛИ". Перефразируя Шварца: "Нам всем говорили, но почему ты оказался самым восприимчивым ?"

F>К тому-же, разработчик — этакая вещь в себе и не может думать за заказчика (да и не должен, если честно).
Не может и не должен, но видеть, к чему приведет его труд — ОБЯЗАН. И если, заранее зная, какие решения неэффективны и приведут неизбежно к переделкам, он не сообщил об этом в команде и (через команду) — Заказчику, то это МИНУС разработчику и команде

F>Иначе работа становится крайне неэффективной. То поведение разработчика, которое вы описали, присуще скорее этаким "домашним" фирмочкам, в которых разработчик и швец и на дуде игрец.

Не согласен. Это присуще практически всем командам, которые делают по-настоящему тиражируемые продукты.

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

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

Здравствуйте, AlexEagle, Вы писали:

AE>Здравствуйте, Equilibrium, Вы писали:

AE>Мне кажется с возрастом это пройдет

"Это" — это что? Жизнь?

В целом согласен.
Похоже мы ситуацию понимаем примерно одинаково, но все же есть свои тонкости.

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

Здравствуйте, bkat, Вы писали:

B>В целом согласен.
B>Похоже мы ситуацию понимаем примерно одинаково, но все же есть свои тонкости.

B>Реальный пример из моей практики, который к теме в общем-то отношения не имеет.
B>Надо было реализовать одну фичу.
B>У маркетинга было 2 (противоположных) взгляда на то,
B>что же на самом деле должен видеть пользователь.
B>Сказать что же предпочтет пользователь
B>без реального продукта было просто невозможно.
B>В итоге мы реализовали оба подхода, продукт вышел на полевые испытания
B>и мы, разработчики, приготовились отключить один из вариантов.
B>Пользователи поигрались с этой фичей и стало
B>понятно что оба предложеных решения плохи. В итоге в релиз эта фича не попала.
B>Т.е. получилось так, что каждый вариант "фичи" был очень точно специфицирован,
B>а вот продукт в целом был неопределен почти до самого конца проекта.
B>Это в общем-то тоже из разряда капризов заказчика,
B>к которым надо быть всегда готовым.

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

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

Ну а удалять... Ломать — не строить. Я не думаю, что удовлетворение подобных мелких "капризов" занимает сколько-нибудь существенное время. Потому о нем то и вспоимнать особо не стоит.

Здравствуйте, SMSM, Вы писали:

SMS>Ну а удалять... Ломать — не строить. Я не думаю, что удовлетворение подобных мелких "капризов" занимает сколько-нибудь существенное время. Потому о нем то и вспоимнать особо не стоит.

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

Здравствуйте, SMSM, Вы писали:

SMS>Профессионализм предполагает, что доделки и переделки продукта сведены к минимуму.

Извините, но это полный бред. Это то же самое, что утверждать, что НДС — 18%, поэтому бухгалтерская программа должна считать его как 18%.
Недавно был в Англии — там НДС — 18.5%. Так что ваша бухгалтерская программа там бы не работала.
Кстати, этот пример — не надуманный. Одно время 1С харткодила ставку НДС 20% в свои программы.
Когда она стала меняться — пришлось переделывать.
Есть уйма факторов, которые предсказать не возможно в принципе. Ряд из них может существенно повлиять
на архитектуру приложения, даже повлечь полную переработку программы.

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

SMS>Если идеи Заказчика абстрактны, то это означает, что команда — разработчик должна так сформулировать и сделать задачу, что должен получиться продаваемый выходной продукт, систематизировав идеи Заказчика и сведя их в некоторую законченную форму, к которой в этой версии продукта ничего ни прибавлять, ни переделывать не требуется.

Одна из классических ошибок при работе с требованиями — додумывать требования за заказчика. Многие бизнес-люди, когда им авторитетно предлагают решение проблемы (из ИТ) ведутся. А потом оказывается, что авторы решения имели ввиду одно, а бизнес-люди — другое. Все требования должен формулировать заказчик и пользователи. Задача аналитика, менеджеров — правильно поставить вопросы.

B>>А для кого тогда инкрементные/итеративные модели жизненных циклов придумали
B>>в которых предполагается, что требования будут меняться и добавляться
B>>по многу раз за время жизни продукта.

SMS>Итеративные модели жизненных циклов действительно имеют ввиду отслеживание времени жизни продукта. Но к нашей дискуссии это имеет мало отношения, так как нормальная работа строится по принципу:
SMS> 1) Делаешь законченный вариант продукта (1 версию)
SMS> 2) Она выпускается в продажу и живет некоторое время самостоятельно
SMS> 3) Команда ведет поддержку продукта, мелкие добавления и исправления ошибок
SMS> 4) Все созданные при разработке материалы систематизируются и готовятся так, чтобы их могла принять другая команда (т.е. составляется
SMS> документация, комментируются и канонизируются (уппрощаются) коды и т.п.
SMS> 5) Команда завершает работу над проектом

SMS>и только далее:
SMS> 6) Группа поддержки, менеджеры и аналитики собирают и систематизируют замечания от потребителей по текущей версии
SMS> 7) Принимается решение о изготовлении версии 2 и ее возможностях
SMS> 8) Создается команда и делается версия 2

SMS> и т.д.

Извини, не верю, что ты работал над сколько либо продолжительным проектом. А что прикажешь делать, если нужно за неделю сделать изменение, иначе компания потеряет денег больше, чем сумма зарплат всех программистов проекта??? Быстро все латать/переделывать. В настоящем бизнесе не бывает законченного варианта продукта (возможно, за исключением простых коробочных программ, навроде нотепада или тетриса). Часто люди компенсируют недостатки программы ручным трудом, формулами в экселе или еще как-то. Если нет проблем с программой, значит либо ее не используют, либо людям слишком сложно донести до разработчиков свои проблемы и они их решают подручными способами. Ты слышал, что иногда менеджеры изучают программирование и пишут на Delphi/1C/FoxPro т.п. программы, так как им нужно здесь и сейчас? Конечно, это не правильно, но это реалии нашей жизни.

Опять же пункт 4 тоже оторван от жизни. Прочитай пару книг/статей по XP. Потом обдумай, сравни XP с RUP, итерационными методами. Я люблю документацию, но не всегда есть экономический смысл в ее ведении. Опять же реалии могут быть такими, что по проекту нет полной документации и взять ее неоткуда.

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

SMS> В жизни часто бывает, что вместо команды 2 берется та же команда 1 и продолжает работу, что создает иллюзию некоторого бесконечного цикла.
SMS> Но это совершенно не так.

Ага. См. выше. Жизнь сложнее.

SMS>Если не разделять жестко версии продукта и не фиксировать окончание работы над очередной версией (с подготовкой полной документации по поддержке), то этот подход приводит к бесконечным альфа- и бета- версиям продуктов, отсутствию по-настоящему отлаженного софта и громадным непроизводительным затратам времени и денег.

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

SMS>Но в дискуссии речь шла о другом: когда разработчик морально вправе покинуть команду без ущерба для репутации и квалификации?.
SMS>Так вот мой ответ: на этапе 5. Т.е. сделанная версия должна быть полностью передана потребителям для работы и Заказчику для поддержки.

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

SMS>Кроме того, я считаю, что при грамотно проведенной предварительной работе команды (менеджеров, аналитиков и консультирующих их программистов) нормальной ситуацией является то, что ни требования, ни технический проект, ни архитектура софта во время разработки на этапах 1-5 не меняются,причем не по чьей-то воле, а потому что нет необходимости их менять (все предусмотрено).

Ага. Дума РФ вводит новые налог, которые твоя программа должна уметь считать. Как ты сможешь его предусмотреть заранее???

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

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

B>>То, что ты описал, возможно только если есть явный заказчик,
B>>который уже почти представляет, что надо делать.
B>>К примеру если Нокиа отдаст часть работ питерской фирме,
B>>то питерская фирма видимо будет иметь дело с хорошо определенными,
B>>редко и не сильно меняющимися требованиями на одной итерации...

SMS>Так здесь и идет речь об одной итерации.
SMS>Но если Вы получили требоваиня, например, от Nokia, то никто не мешает Вам их обдумать, проверить, приложить к себе, понять, имеют ли они некоторую законченную для версии форму. И если не имеют, то никто не мешает Вам сформулировать свое видение вопроса и предложить его Заказчику.
SMS>Конечно, решать в любом случае будет он, но предупредить его о последствиях тех или иных решений, на которые он, возможно, не обращал внимание, дополнить его видение вопроса до большей законченности — это прямая обязанность команды (если она заинтересована в результате, а не просто в получении от него денег). Разумные предложения западные Заказчики (и Nokia в частности) обычно принимают — нужно только грамотно все разъяснить, если потребуется — на примерах и макетах.

Такое работает очень редко и, как правило, когда речь идет о компромисе между сложностью/стоимостью и функциональностью.

B>>А если ты разрабатываешь, к примеру, новый Word, то настоящий отклик пойдет только
B>>после первого релиза...

SMS>Так о первом релизе и идет речь — как о результате деятельности команды. Разработка того, что войдет во второй релиз — это работа команды N 2 (часто той же самой). Важно, чтобы работа над ошибками в релизе 1 была сведена к минимуму.

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

SMS>Когда же готовишь релиз 1 продукта, то нужно (и это возможно) формулировать так ТЗ и постановки, чтобы он:
SMS>- имел законченный вид

Не реально. Чтобы убедиться, попробуй сформилировать точные критерии ТЗ, которое имеет законченный вид.
Всегда какая-то часть требований остается недосказанной. Здесь становятся важны приоритеты, общая осведомленность команды, знание предметной области, хорошие коммуникативные навыки.

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

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

B>>В общем если контора продвинута, то разработчики скорей всего действительно имеют
B>>дело с четкими требованиями, но они гарантированно будут меняться/добавляться
B>>в ходе жизни продукта. Речь идет именно об этом...

SMS>Разработчиков, имеющих дело с заранее четко определенными требованиями Заказчика я не встречал. Но в нормаьлных командах после грамотно проведенной предварительной работы всей команды (менеджеров, аналитиков, консультантов-программистов, обсуждений с Заказчиком) вырабатываются действительно четкие требования к релизу продукта, что позволяет успешно решать этапы 1 — 5.

. ИМХО, причинно-следственная связь не верная. Из-за профессионализма команды в области разрешения непредвиденных проблем она успешно решает этапы 1-5 и все прочие, если нужно будет. Четкость требований не всегда является обязательным требованием и не всегда достигается.

ИМХО, шире смотри на жизнь. Она интересная .

Здравствуйте, Equilibrium, Вы писали:

Насколько я вас понял — под термином "работа" подразумевается "место работы", а под "профессиональным ростом" вы понимаете умение выполнять работу, требующую большего объёма знаний, умений и опыта (и, как следствие, более высокую оплату). Далее буду аппелировать исходя из этих предпосылок.

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


Теперь попунктно.

E>Когда вы работаете с новым проектом, вы получаете новый ценный опыт.

В каком-то процентк случаев — да. Однако, что мешает работать с новым проектом не меняя места работы (это общее высказывание, поскольку есть варианты, когда это невозможно, но эти варианты менее типичны).

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

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

E>Поэтому самый оптимальный опыт — это один законченный крупный проект и максимальное количество законченных средних и мелких проектов. Крупный проект даёт опыт работы с большими и сложными системами. Такие системы качественно отличаются, они как правило высокобюджетные и их реализация требует более высокой квалификации. Для вас это значит, что вы после реализации такого проекта сможете получать на новом месте бОльшую зарплату.
E>Мелких проектов может быть гораздо больше, чем крупных, и они дадут много разнообразного опыта. Поэтому самый оптимальный опыт — это 1-2 крупных проекта и максимальное количество мелких и средних. Это даст максимальное развитие.

Это ИМХО неверно от начала и до конца.


E>Почему надо менять работу чаще?

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

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

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

Как уже было произнесено в одном из ответов — период поддержки можно грамотно использовать:
1) для анализа того, что вы сделали
2) для самообразования и подготовки к следующим проектам
3) для отдыха (имеется ввиду снижение нагрузки)
и т.д.

Т.е. данный период — это один из лучших периодов в жизни программиста

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

Вот здесь вы ошибаетесь очень сильно. Работодатель предпочитает"стабильных" работников потому, что:
— на них можно расчитывать, их работоспособность и навыки известны, с ними можно нормально планировать;
— понижаются риски проекта, поскльку риск ухода сотрудника в процессе проекта ниже;
— "стабильные" сотрудники знают бизнес-процессы компании, работают в рамках этих бизнес--процессов -- их не надо обучать и приживлять, как новичков;
— как правило, "стабильные" работников составляют костяк коллектива, что влияет на моральных дух команды...

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

А насчёт меньшшей оплаты "стабильных" сотрудников — здесь не совсем вообще понятно, откуда эта информация.

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

Соблазнять работодателя не надо — он не секретаршу себе берёт, а работника в компанию. Тем более, если вас действительно берут в компанию, а не на реализацию конкретного проекта.

Кстати, в вашем случае могу дать совет — попробуйте поработать в офшорной компании, где набирают народ из пула работников в команду на конкретный проектт. Схема там простая — пока вы на скамье (ждёте проекты) — вам платят гроши. Если вы попадаете в очередной проект (вас выбирают как хорошего специалиста) — вам резко повышают зарплату до окончания проекта. Там сможете повышать свой уровень согласно предложенной вами теории и место работы не менять. Идеально.

Здравствуйте, mikkri, Вы писали:

M>Ага. Дума РФ вводит новые налог, которые твоя программа должна уметь считать. Как ты сможешь его предусмотреть заранее???

Так программа никогда не будет написана Конечно, это не очень невероятная ситуация, и именно поэтому надо начинать что-то делать, когда есть утвержденная с заказчиком спецификация продукта. В ней должна быть детально указана вся функциональность и сроки сдачи проекта. ЛЮБЫЕ изменения в спецификации могут быть сделаны ТОЛЬКО на основе совещаний с представителями заказчика, при этом возможно урезание существующей функциональности, чтобы сохранить бюджет пректа или заказчик должен согласиться оплатить дополнительную работу.

Здравствуйте, Alexey_ch, Вы писали:

A_>Здравствуйте, mikkri, Вы писали:

M>>Ага. Дума РФ вводит новые налог, которые твоя программа должна уметь считать. Как ты сможешь его предусмотреть заранее???

A_>Так программа никогда не будет написана Конечно, это не очень невероятная ситуация, и именно поэтому надо начинать что-то делать, когда есть утвержденная с заказчиком спецификация продукта. В ней должна быть детально указана вся функциональность и сроки сдачи проекта. ЛЮБЫЕ изменения в спецификации могут быть сделаны ТОЛЬКО на основе совещаний с представителями заказчика, при этом возможно урезание существующей функциональности, чтобы сохранить бюджет пректа или заказчик должен согласиться оплатить дополнительную работу.

С дополнением полностью согласен. И, насколько я понимаю, оно не противоречит моему посту?

Здравствуйте, mikkri, Вы писали:

M>Здравствуйте, SMSM, Вы писали:

SMS>>Профессионализм предполагает, что доделки и переделки продукта сведены к минимуму.

M>Извините, но это полный бред. Это то же самое, что утверждать, что НДС — 18%, поэтому бухгалтерская программа должна считать его как 18%.
M>Недавно был в Англии — там НДС — 18.5%. Так что ваша бухгалтерская программа там бы не работала.
M>Кстати, этот пример — не надуманный. Одно время 1С харткодила ставку НДС 20% в свои программы.
M>Когда она стала меняться — пришлось переделывать.

Типичный пример неграмотного проектирования. Поэтому и пришлось переделывать.

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

Да, такие факторы бывают. Но в том и состоит искусство и профессионализм команды проектировщиков, чтобы свести к минимуму влияние подобных факторов на проект. То, что Вы не знаете, как это делается, значит, что Вы не видели хороших ТЗ и постановок, а сами таковые формулировать не научились.

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

А это хамство. Но отвечу: я думаю, что на бирже место как раз Вам с готовностью плыть по любому первому попавшемуся течению "непредсказуемых факторов".
Я же считаю, что профессиональная разработка софта — процесс планируемый, достаточно хорошо прогнозируемый заранее с минимальным влиянием неучтенных факторов, наличие которых к тому же чаще всего можно предсказать и подготовиться к ним.
Возвращаясь к тому же НДС. Этот налог едва ли не самый часто изменяющийся за время существования России после 1991 года. При этом теоретические обобщенные модели (их несколько), по которым он может рассчитываться, известны чуть ли не со времен Адама Смита. Поэтому никто не мешал предусмотреть грамотный расчет этого налога заранее, с тем чтобы его изменение вело к минимальным переделкам, что разработчики ряда программ и сделали. Нужно было только немного подумать, прежде чем проектировать. 1C этого не сделали и, естественно, новая ставка стала "непредсказуемым фактором".

SMS>>Если идеи Заказчика абстрактны, то это означает, что команда — разработчик должна так сформулировать и сделать задачу, что должен получиться продаваемый выходной продукт, систематизировав идеи Заказчика и сведя их в некоторую законченную форму, к которой в этой версии продукта ничего ни прибавлять, ни переделывать не требуется.

M>Одна из классических ошибок при работе с требованиями — додумывать требования за заказчика. Многие бизнес-люди, когда им авторитетно предлагают решение проблемы (из ИТ) ведутся. А потом оказывается, что авторы решения имели ввиду одно, а бизнес-люди — другое. Все требования должен формулировать заказчик и пользователи.

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

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

M>Задача аналитика, менеджеров — правильно поставить вопросы.
Разумеется...
Но случается, и довольно часто, что задаешь сотруднику Заказчика вопросы, получаешь ответы в разговоре или в письменной форме, анализируешь их, формулируешь постановку, а потом понаблюдаешь за работой того же сотрудника — и постановка рассыпается. Акценты оказываются в реальной жизни выставлены вовсе не так, как следует из ответов на заданные вопросы. А если это выясняется уже после того, как система сделана? Начинаются различного рода заплатки и якобы "неучтенные факторы".

Поэтому задача менеджера и аналитиков — сформулировать в совместной работе с Заказчиком, на основе учета интересов потребителей, продукта и с учетом консультаций с разработчиками, ТЗ и постановки для разработки, а не только "правильно задавать вопросы".

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

B>>>А для кого тогда инкрементные/итеративные модели жизненных циклов придумали
B>>>в которых предполагается, что требования будут меняться и добавляться
B>>>по многу раз за время жизни продукта.

SMS>>Итеративные модели жизненных циклов действительно имеют ввиду отслеживание времени жизни продукта. Но к нашей дискуссии это имеет мало отношения, так как нормальная работа строится по принципу:
SMS>> 1) Делаешь законченный вариант продукта (1 версию)
SMS>> 2) Она выпускается в продажу и живет некоторое время самостоятельно
SMS>> 3) Команда ведет поддержку продукта, мелкие добавления и исправления ошибок
SMS>> 4) Все созданные при разработке материалы систематизируются и готовятся так, чтобы их могла принять другая команда (т.е. составляется
SMS>> документация, комментируются и канонизируются (уппрощаются) коды и т.п.
SMS>> 5) Команда завершает работу над проектом

SMS>>и только далее:
SMS>> 6) Группа поддержки, менеджеры и аналитики собирают и систематизируют замечания от потребителей по текущей версии
SMS>> 7) Принимается решение о изготовлении версии 2 и ее возможностях
SMS>> 8) Создается команда и делается версия 2

SMS>> и т.д.

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

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

M>В настоящем бизнесе не бывает законченного варианта продукта (возможно, за исключением простых коробочных программ, навроде нотепада или тетриса). Часто люди компенсируют недостатки программы ручным трудом, формулами в экселе или еще как-то.

Я чего-то не понял. Вы для чего делаете программы? Чтобы при этом люди еще работали в Excel?
А вообще-то Ваша фраза еще раз подчеркивает, что нужно грамотно проводить предварительную работу.

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

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

M>Ты слышал, что иногда менеджеры изучают программирование и пишут на Delphi/1C/FoxPro т.п. программы, так как им нужно здесь и сейчас? Конечно, это не правильно, но это реалии нашей жизни.

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

M>Опять же пункт 4 тоже оторван от жизни. Прочитай пару книг/статей по XP. Потом обдумай, сравни XP с RUP, итерационными методами.
Я не сильно активный читатель подобных фолиантов. Все мои мысли взяты из жизни и из моего собственного опыта работы (довольно большого).

M>Я люблю документацию, но не всегда есть экономический смысл в ее ведении.
Разумеется, если Вы постоянно занимаетесь заплатками, вместо грамотного планирования и выполнения проекта, то вести документацию не имеет никакого экономического смысла. Но к качественному продукту и к тому, что я говорил это не имеет никакого отношения.

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

M>Вообщем, недопонимаешь ты итерационный подход. Итерационность не значит, что все делается цеклично и последовательно.
Разумеется, не значит. Жизнь богаче. Я лишь описывал ситуацию к которой нужно стремиться — и которую часто можно получить при грамотной работе.
Но приписывать массовую практику устранения "неучтенных факторов" итерационному подходу тоже не следует. Это просто самооправдание постоянных заплаток.

M>Обычно эффективно накладывать шаги итераций друг на друга.
M>Так же иногда реалии жизни заставляют запускать мини итерации в самые неожиданные моменты.
Да, бывают такие случаи. Но если это обычная практика для Вас — то это очень печально.

M>Собственно, зачем тогда в системах контроля версий так много внимания уделяют бранчам?..
При чем тут система контроля версий, я честно говоря не понял. Я говорил о проблемах другого уровня.

SMS>> В жизни часто бывает, что вместо команды 2 берется та же команда 1 и продолжает работу, что создает иллюзию некоторого бесконечного цикла.
SMS>> Но это совершенно не так.

M>Ага. См. выше. Жизнь сложнее.
Вы, похоже этим довольны? Я Вам не завидую. Я стремлюсь не создавать себе и окружающим сложные ситуации и потом их решать заплатками на "неучтенные факторы", а наоборот, предусматривать их заранее и избегать. Ей-богу это интересней.

SMS>>Если не разделять жестко версии продукта и не фиксировать окончание работы над очередной версией (с подготовкой полной документации по поддержке), то этот подход приводит к бесконечным альфа- и бета- версиям продуктов, отсутствию по-настоящему отлаженного софта и громадным непроизводительным затратам времени и денег.

M>Опять же могу сказать, что жизнь сложнее. Бывают ситуации, когда эти самые непроизводственные затраты времени и денег (как ты выразился) ведут к экономии много большего количества времени пользователей и увеличению (или не потере) денег компанией.

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

SMS>>Но в дискуссии речь шла о другом: когда разработчик морально вправе покинуть команду без ущерба для репутации и квалификации?.
SMS>>Так вот мой ответ: на этапе 5. Т.е. сделанная версия должна быть полностью передана потребителям для работы и Заказчику для поддержки.

M>Если честно, я не понял, чем уход на 1 месяц раньше хуже. А если учесть, что серьезные программы обычно развертывают последовательно, первые продакшен проблемы могут быть и через месяц, и через два. Некоторые ERP системы вообще годами внедряют. Человек морально вправе уходить, когда не подведет команду. Сроки здачи проекта лишь один из факторов.

Видите ли, окончание проекта обычно просто так не задерживается, но только по каким-либо важным причинам. Если после ухода Ваш софт приходится в спешке переделывать другим, чего можно было бы избежать, задержись Вы на месяц до окончания проекта, то по-моему — это совсем не очень хорошая ситуация (хотя бы с моральной точки зрения).

SMS>>Кроме того, я считаю, что при грамотно проведенной предварительной работе команды (менеджеров, аналитиков и консультирующих их программистов) нормальной ситуацией является то, что ни требования, ни технический проект, ни архитектура софта во время разработки на этапах 1-5 не меняются,причем не по чьей-то воле, а потому что нет необходимости их менять (все предусмотрено).

M>Ага. Дума РФ вводит новые налог, которые твоя программа должна уметь считать. Как ты сможешь его предусмотреть заранее???
Вынеси расчет формулы налога за рамки основного движка — и это изменение будет довольно незначительным. Кроме того, большинство решений Думы по этой тематике прогнозируются хотя бы за 3 месяца, а то и за полгода.

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

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

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

B>>>То, что ты описал, возможно только если есть явный заказчик,
B>>>который уже почти представляет, что надо делать.
B>>>К примеру если Нокиа отдаст часть работ питерской фирме,
B>>>то питерская фирма видимо будет иметь дело с хорошо определенными,
B>>>редко и не сильно меняющимися требованиями на одной итерации...

SMS>>Так здесь и идет речь об одной итерации.
SMS>>Но если Вы получили требоваиня, например, от Nokia, то никто не мешает Вам их обдумать, проверить, приложить к себе, понять, имеют ли они некоторую законченную для версии форму. И если не имеют, то никто не мешает Вам сформулировать свое видение вопроса и предложить его Заказчику.
SMS>>Конечно, решать в любом случае будет он, но предупредить его о последствиях тех или иных решений, на которые он, возможно, не обращал внимание, дополнить его видение вопроса до большей законченности — это прямая обязанность команды (если она заинтересована в результате, а не просто в получении от него денег). Разумные предложения западные Заказчики (и Nokia в частности) обычно принимают — нужно только грамотно все разъяснить, если потребуется — на примерах и макетах.

M>Такое работает очень редко и, как правило, когда речь идет о компромисе между сложностью/стоимостью и функциональностью.

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

B>>>А если ты разрабатываешь, к примеру, новый Word, то настоящий отклик пойдет только
B>>>после первого релиза...

SMS>>Так о первом релизе и идет речь — как о результате деятельности команды. Разработка того, что войдет во второй релиз — это работа команды N 2 (часто той же самой). Важно, чтобы работа над ошибками в релизе 1 была сведена к минимуму.

M>Нередко имеет смысл накладывать шаги итераций друг на друга. Тогда работа над ошибками в рамках второй итерации может начаться задолго до окончания первой итерации. Не нужно упрощать жизнь — она сложнее любой модели.

Если это делают 2 разные команды — то почему бы и нет. Если же одна и та же команда разрабатывает новую версию, не закончив старую, то это ведет лишь к альфа- и бета-версиям в лучшем случае, а не к законченному продукту. Бывает, что для разработки 2 версии программы нужен тот же разработчик, который выполнил свою работу над первой и остался на поддержке. Но это лишь означает (при правильной организации работы), что человек одновременно участвует в 2 проектах, причем с акцентом на второй.

SMS>>Когда же готовишь релиз 1 продукта, то нужно (и это возможно) формулировать так ТЗ и постановки, чтобы он:
SMS>>- имел законченный вид

M>Не реально. Чтобы убедиться, попробуй сформилировать точные критерии ТЗ, которое имеет законченный вид.
M>Всегда какая-то часть требований остается недосказанной. Здесь становятся важны приоритеты, общая осведомленность команды, знание предметной области, хорошие коммуникативные навыки.

Абсолютно реально. Вы просто не работали с хорошими аналитиками.

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

M>Это уже к маркетологам и первоначальной постановке вопроса. Опять же жизнь может все перевернуть с ног на голову. К примеру, ты писал программу оптимизации налогооблажения. Т.е. как заполнить декларацию, чтобы максимально воспользоваться всеми льготами (возможно, взаимоисключающими). Вдруг правительство приняло закон об упрощенной системе налогооблажения и все твои потенциальные клиенты перешли на фиксированную ставку. Все, рынка нет, хоть и требования первоначально были собраны, допустим, отлично.

Ну что делать. Бывает...
Только кто мешал самому поинтересоваться, что творится в Думе (если уж собираешься тратить время на эту тему) и подумать, прежде чем браться за работу? Может быть тогда и не жалел бы о напрасно потраченном времени.
(Еще раз: не следует понимать меня так, что я рекомендую самому заменить маркетологов. Нет. Но провести небольшую личную проверку и принять решение о свое участии/неучастии в проекте, да и задать дополнительные вопросы маркетологам — кто мешает?)

B>>>В общем если контора продвинута, то разработчики скорей всего действительно имеют
B>>>дело с четкими требованиями, но они гарантированно будут меняться/добавляться
B>>>в ходе жизни продукта. Речь идет именно об этом...

SMS>>Разработчиков, имеющих дело с заранее четко определенными требованиями Заказчика я не встречал. Но в нормаьлных командах после грамотно проведенной предварительной работы всей команды (менеджеров, аналитиков, консультантов-программистов, обсуждений с Заказчиком) вырабатываются действительно четкие требования к релизу продукта, что позволяет успешно решать этапы 1 — 5.

M>. ИМХО, причинно-следственная связь не верная. Из-за профессионализма команды в области разрешения непредвиденных проблем она успешно решает этапы 1-5 и все прочие, если нужно будет. Четкость требований не всегда является обязательным требованием и не всегда достигается.

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

M>ИМХО, шире смотри на жизнь. Она интересная .
Жизнь действительно интересная. Хочется (и мне удается) сделать многое. Удастся еще больше, но только если я не буду постоянно решать "непредвиденные проблемы". А то никакой жизни не хватит.

Здравствуйте, Spidola, Вы писали:

S>Кстати, в вашем случае могу дать совет — попробуйте поработать в офшорной компании, где набирают народ из пула работников в команду на конкретный проектт. Схема там простая — пока вы на скамье (ждёте проекты) — вам платят гроши. Если вы попадаете в очередной проект (вас выбирают как хорошего специалиста) — вам резко повышают зарплату до окончания проекта. Там сможете повышать свой уровень согласно предложенной вами теории и место работы не менять. Идеально.

Можно подробнее, просто имеется немного свободного времени регулярно, и хотелось бы добавить себе в финанасах

Здравствуйте, AlexEagle, Вы писали:

AE>Здравствуйте, Spidola, Вы писали:

S>>Кстати, в вашем случае могу дать совет — попробуйте поработать в офшорной компании, где набирают народ из пула работников в команду на конкретный проектт. Схема там простая — пока вы на скамье (ждёте проекты) — вам платят гроши. Если вы попадаете в очередной проект (вас выбирают как хорошего специалиста) — вам резко повышают зарплату до окончания проекта. Там сможете повышать свой уровень согласно предложенной вами теории и место работы не менять. Идеально.

AE>Можно подробнее, просто имеется немного свободного времени регулярно, и хотелось бы добавить себе в финанасах

К сожалению, конкретную контору не скажу, но у нас работал сотрудник как раз из такой компании. Там была следующая ситуация — если нет проектов, то всем снижали З/П до 500 USD в месяц и ставили на hold (т.е. человек вроде на работу ходит, но там реальными проектами не занимается). Там это называлось "сесть на скамью". Если появляется заказ, то менеджерами набирается команда их свободных сотрудников, подходящих по квалификации и опыту и согласными на предложенную в рамках проекта компенсацию. Сотрудник может и отказаться, но все отказы фиксируются и зарплата на скамеечный период постепенно уменьшается, а потом и вовсе может пропасть.

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

У меня один из бывших сотрудников работал в такой компании, но как на основной работею. Как подработка это, думаю, не пойдёт...

mikkri wrote:
>
> SMS> 4) Все созданные при разработке материалы систематизируются и
> SMS> готовятся так, чтобы их могла принять другая команда (т.е. составляется
> SMS> документация, комментируются и канонизируются (уппрощаются) коды и т.п.

> Опять же пункт 4 тоже оторван от жизни. Прочитай пару книг/статей по XP.

Вот эту, про Extreme Programming Considered Harmful ?

http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf

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

См. ссылку

Mikhail

Здравствуйте, Equilibrium, Вы писали:

E>Есть вакансии team leader и PM, туда можно прийти со стороны вместо того, чтобы вырасти внутри фирмы постоянного работодателя. Такой путь быстрее.

Обрати внимание никто на такие вакансии не берет людей без опыта работы этиам самым Team Leader-ом или PM-ом.