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

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

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

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

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

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

Все верно с точнойстью до нескольких моментов:
0) Профессиональный рост — не самоцель. Цель — заработать деньги своими мозгами.
1) Вы навсегда останетесь программистом и никогда не займете руководящую позицию, поскольку на такие позиции выдвигают людей с длительным стажем работы в данной организации. А следовательно никогда не заработаете значительно бОльших денег, чем получают любые программисты.
2) Рано или поздно вас перестаунут брать на работу, поскольку работодатели, как Вы сами верно сказали, хотят стабильных сотрудников. И когда они видят в резюме, что вы нигда не работали больше 6-10 месяцев просто перестанут Вас брать на работу на этом основании.
3) Поддержка продукта — вовсе не бесполезный этап, поскольку именно на этапе поддержки Вы и начинаете понимать насколько удобный-неудобный для пользователя / устойчивый-не устойчивый продукт Вы написали. Ведь продукты пишутся для пользователей и фактически Вы предлагаете сбежать из компании в тот момент, когда Ваш продукт начинает использоваться и Вы начинаете получать реальную оценку своей работы (от тех, для кого Вы писали продукты). Только использование продукта в реальных условиях у клиента является настоящим испытанием для продукта — никакой отдел тестирования не заменит эту реальную проверку. В тестувую лабу можно сходить -поотлаживаться, к клиенту не сходишь — надо учиться отлаживаться удаленно. Тоже по системе создания логов программы — лог файл — часто единственное, что присылает Вам клиент, когда говорит, что все упало. Вобщем, с моей точки зрения, Поддержка — это огромный опыт, когда Вы и делаете главные выводы о том насколько качественный Ваш код. Программист, никогда не участвующий в саапорте клиента — на порядок слабее того, кто участвовал.

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

GUI>3) Поддержка продукта — вовсе не бесполезный этап, поскольку именно на этапе поддержки Вы и начинаете понимать насколько удобный-неудобный для пользователя / устойчивый-не устойчивый продукт Вы написали.

Согласен на все 100.
Только со временем вылезут наружу все архитектурные просчеты.
Станет понятно, насколько быстро и безболезненно
можно расширять функциональность и править баги.

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

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

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

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

GUI>Все верно с точнойстью до нескольких моментов:
GUI>0) Профессиональный рост — не самоцель. Цель — заработать деньги своими мозгами.


Да. Абсолютно.


GUI>1) Вы навсегда останетесь программистом и никогда не займете руководящую позицию, поскольку на такие позиции выдвигают людей с длительным стажем работы в данной организации. А следовательно никогда не заработаете значительно бОльших денег, чем получают любые программисты.


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


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


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


GUI>3) Поддержка продукта — вовсе не бесполезный этап, поскольку именно на этапе поддержки Вы и начинаете понимать насколько удобный-неудобный для пользователя / устойчивый-не устойчивый продукт Вы написали.


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

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

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

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

Ксати, а что такое профессиональное развитие?
Что ты под этим понимаешь?

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

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

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

B>Ксати, а что такое профессиональное развитие?
B>Что ты под этим понимаешь?

Опыт, навыки, знания.

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

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

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

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

B>>Ксати, а что такое профессиональное развитие?
B>>Что ты под этим понимаешь?

E>Опыт, навыки, знания.

Опыт, навыки и знания сами по себе — пустой и никчемный груз. Приложение опыта, навыков и знаний — всего лишь их приложение. Так что тема "что такое профессиональное развитие" не раскрыта.

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

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

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

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

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

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

B>>Ксати, а что такое профессиональное развитие?
B>>Что ты под этим понимаешь?

E>Опыт, навыки, знания.

Это все слова...
Опыт тоже бывает разным. Например опыт работы с капризными клиентами,
от которого ты видимо отмахиваешься...

В общем я не против смены работы, но с частотой раз в 3-5 лет.
А вообще для меня лично лучше найти фирму, где бы и 20 лет было бы интересно.
Такие места в общем-то есть...

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

B>>>Ксати, а что такое профессиональное развитие?
B>>>Что ты под этим понимаешь?

E>>Опыт, навыки, знания.

F>Опыт, навыки и знания сами по себе — пустой и никчемный груз. Приложение опыта, навыков и знаний — всего лишь их приложение. Так что тема "что такое профессиональное развитие" не раскрыта.


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

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

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

B>>>>Ксати, а что такое профессиональное развитие?
B>>>>Что ты под этим понимаешь?

E>>>Опыт, навыки, знания.

F>>Опыт, навыки и знания сами по себе — пустой и никчемный груз. Приложение опыта, навыков и знаний — всего лишь их приложение. Так что тема "что такое профессиональное развитие" не раскрыта.


E>Опыт, навки и знания позволяют подороже продаться на рынке труда.
E>Работа — это источник денег, а не простое следование общественным стереотипам.

Если для тебя работа — это только источник денег,
то вершин (по крайней мере в программировании) ты не достигнешь.

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

GUI>>1) Вы навсегда останетесь программистом и никогда не займете руководящую позицию, поскольку на такие позиции выдвигают людей с длительным стажем работы в данной организации. А следовательно никогда не заработаете значительно бОльших денег, чем получают любые программисты.
E>Есть вакансии team leader и PM, туда можно прийти со стороны вместо того, чтобы вырасти внутри фирмы постоянного работодателя. Такой путь быстрее.
А как вы сможете аргументировать, что вы сможете выполнять работу тим лида или менеджера проекта, если вы всегда были просто программистом? Для обоих позиций важны не только технические знания, но и умения работать с людьми и быть отвественным человеком, а частые смены мест работы говорят как раз об обратном.

GUI>>2) Рано или поздно вас перестаунут брать на работу, поскольку работодатели, как Вы сами верно сказали, хотят стабильных сотрудников. И когда они видят в резюме, что вы нигда не работали больше 6-10 месяцев просто перестанут Вас брать на работу на этом основании.
E>Средний период из "полгода-полтора года" — год. Это нормально. Нижней границы лучше пока не придерживаться, потому что работодатели ещё не готовы воспринимать это нормально. Их надо подготовить к этому постепенно.
Если вы начинаете заниматься серьезным проектом, то вам потребуется время что бы:
1) Разобраться в предметной области
2) Изучить правила работы в той фирме в которую вы устроились
3) Изучить новые для вас технологии
4) Разобраться в том, что было сделано в проекте до вас
Как правило, на это уходит от 2 до 3-6 месяцев.
Таким образом, на продуктивную работу останется 6-7 месяцев (маловато будет!).
Если же проект мелкий, то на нем вы не сможете изучить новые технологии в полной мере, и соответственно нельзя будет сказать что вы стали специалистом в выбранной вами области.

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

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

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

B>>Ксати, а что такое профессиональное развитие?
E>Опыт, навыки, знания.

Уровень профессионализма определяется не только — и не столько — количеством опыта, навыков, знаний, но и их качественной строной.
Одной из важнейших качественных характеристик является способность рассмотреть свою работу с различных сторон. Увеличивающиеся объемы ваших знаний, окружая вас, неизбежно заслонят от вас все то, что находится за их кругом; а вы вместо того, чтобы подняться из этого столпотворения и осмотреть свалку со стороны, стремитесь наоборот, только глубже закопаться в этой куче.
Вы напоминаете музыканта, никогда не встречающегося с публикой; не знающего судьбы его произведений; и более того — не догадывающегося, что кроме пяти знакомых ему аккордов, во владении которыми он совершенствуется всю жизнь, существуют и другие.

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

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

B>Если для тебя работа — это только источник денег,
B>то вершин (по крайней мере в программировании) ты не достигнешь.

Вершины в программировании — это не цель, а средство. Средство зарабатывать деньги.

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

S>А как вы сможете аргументировать, что вы сможете выполнять работу тим лида или менеджера проекта, если вы всегда были просто программистом?


Тимлидерами не рождаются, а становятся. Сначала человек работает программистом, потом становится тимлидером, если способности позволяют.


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


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



S>Если вы начинаете заниматься серьезным проектом, то вам потребуется время что бы:
S>1) Разобраться в предметной области


Только в пределах надобности для проекта.


S>2) Изучить правила работы в той фирме в которую вы устроились


Это очень просто.


S>3) Изучить новые для вас технологии


А если бОльшая часть их уже изучена?


S>Таким образом, на продуктивную работу останется 6-7 месяцев (маловато будет!).


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


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


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


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


Это какие-то странности. Работа в крупной компании ещё ничего определённого не значит.


S>2) Иметь суммарный опыт работы программистом от 7-10 лет
S>3) Иметь качества тим-лида и менеджера


Почти согласен.

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

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

B>>Если для тебя работа — это только источник денег,
B>>то вершин (по крайней мере в программировании) ты не достигнешь.

E>Вершины в программировании — это не цель, а средство. Средство зарабатывать деньги.

А как же fun от работы?
Скучно только о деньгах думать...

Впрочем это уже уход от темы.

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


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

E>Говорят только для того, кто судит о качествах человека по его активности/пассивности. Для меня частота смены работ — это мера активности/пассивности жизненной позиции, а не ответственности.
Ага, только одно дело, когда из-за своей "активной жизненной позиции" сваливает с проекта программер, а другое — тимлидер

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

E>Работа — это источник денег, а не простое следование общественным стереотипам.

Долго хохотал Самый общественный стереотип — это "работа — источник денег"
Так что тема опять не раскрыта

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

[]

E>Вершины в программировании — это не цель, а средство. Средство зарабатывать деньги.

Хочу вас огорчить — те времена, когда в программировании одиночки зарабатывали миллионы, давно прошли. Сейчас программированием _много_ денег не заработаешь. Много — это много, а не 2000-3000-4000 долларов в месяц. Может, вы не ту профессию выбрали?

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

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

F>[]

E>>Вершины в программировании — это не цель, а средство. Средство зарабатывать деньги.

F>Хочу вас огорчить — те времена, когда в программировании одиночки зарабатывали миллионы, давно прошли. Сейчас программированием _много_ денег не заработаешь. Много — это много, а не 2000-3000-4000 долларов в месяц. Может, вы не ту профессию выбрали?

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

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

[]

F>>Хочу вас огорчить — те времена, когда в программировании одиночки зарабатывали миллионы, давно прошли. Сейчас программированием _много_ денег не заработаешь. Много — это много, а не 2000-3000-4000 долларов в месяц. Может, вы не ту профессию выбрали?

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

Понятие "максимум" в приложении к зарплате — вещь сугубо эмпирическая. Обладающая свойствами в прогрессии увеличивать свою верхнюю границу по достижении примерно 80% от текущего понятия "максимум". Проще говоря — денег много не бывает.

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

И появится у нас новый продакт-манагер

Здравствуйте, 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-ом.

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

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

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

Специально для таких как ты:

"Considered Harmful" Considered Harmful
http://www.deez.info/sengelha/writings/considered-harmful/

_vovin wrote:
>
> Здравствуйте, kittown, Вы писали:
>
> Специально для таких как ты:
>
> "Considered Harmful" Considered Harmful
> http://www.deez.info/sengelha/writings/considered-harmful/

Это называется overreacting. Здесь вроде не инстирут
благородных девиц ?

Mikhail

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

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

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

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

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

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

Уважаемый SMSM, вы вроде бы и правильные вещи говорите, но меня никак не покидает ощущение, что ваши рассуждения оторваны от реальности.

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

SMS>Заказчик задает лишь общие рамки функционала, сроки и бюджет.

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

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

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

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

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

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

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

S>Какая странная контора. У нас, например, заказов почти всегда больше, чем мы способны сделать. Это даже если не браться за те работы, которые под силу сделать только индийцам из-за низкого уровня оплаты. Такого чтобы кто-то сидел без работы в принципе нет.

Так понимаю, что объём заказов подвержен колебаниям, начиная от сезонных, и заканчивая экономическими в странах, для которых делаются заказы.

Ну и ещё встречаются нерадивые менеджеры, ищущие заказы

К нам человек попал в компанию как раз из описываемой мною конторы после известного спада активности на IT рынке два с половиной года назад, когда всех высадили "на лавку"...

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

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

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

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

S>Уважаемый SMSM, вы вроде бы и правильные вещи говорите, но меня никак не покидает ощущение, что ваши рассуждения оторваны от реальности.
Вообще-то у меня на счету достаточное кол-во постановок и ТЗ, по которым разработан и внедрен софт. Некоторые запатентованы Заказчиками на Западе. Так что здесь я излагаю исключительно собственные подходы и собственный опыт.
Кстати, я и появляюсь на форуме не слишком часто, так как в основном занят. Сейчас просто болею (нахожусь дома) — и потому отвечаю чаще.

А конкретика: в подобных вопросах конкретика проявляется исключительно в приложении к конкретным задачам.

S>По моим наблюдениям, в большинстве случаев заказчики в состоянии описать самостоятельно лишь самые общие требования к системе. И этой информации недостаточно, чтобы приступить к проектирвоанию, а самостоятельное додумывание требований действительно чревато, особенно если идет речь об автоматизации каких-то специфических бизнес-процессов, неведомых стороннему разработчику.

SMS>>Заказчик задает лишь общие рамки функционала, сроки и бюджет.

S>Вот вы сами и говорите, что заказчик дает лишь общие рамки функционала.

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

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

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

По технике:
1) Конечно, вопросы.
Однако вопросы, заданные Заказчику и его представителям позволяют понять только основные цели, которые преследует Заказчик, начиная разработку и причины, почему его не устраивают другие, возможно менее затратные решения.
2) Я исхожу из того, что ничто не ново под луной, и практически все задачи, которые нужны, уже решались кем-то до нас, полностью или частично. Поэтому безотносительно к Заказчику я стараюсь сам тщательно познакомиться с опытом решения подобных (или близких к подобным) задач другими командами, в других предприятиях, компаниях. Меня интересует все:
— теоретические основы применяемых алгоритмов
— оценки применений тех или иных моделей бизнес-процессов (не обязательно в софте) и решений на практике
— бизнес-процессы, реализованные в софте и показатели применения готового софта на практике, интерфейсы софта, удачи и проблемы
— теоретические идеи по поводу того, как было бы хорошо решать подобные задачи (иногда и в них попадаются ценные зерна).
и т.д.
Таким образом я составляю собственное представление о том, как наиболее эффективно решить затруднения Заказчика
3) Если идет речь об автоматизации функций сотрудника, то я обязательно провожу 1 — 2 дня рядом с сотрудником и просто наблюдаю за тем, что он делает, не задавая никаких вопросов. Если удается, то лучше инкогнито, например, просто под маской временно нанятого сотрудника, работающего в той же комнате. Это позволяет понять, как построить будущий софт, чтобы он приносил реальную пользу. Полезно также, если есть два сотрудника, выполняющих похожие функции, понаблюдать за работой одного (самого успешного), а потом задать вопросы другому (менее успешному) с тем, чтобы он описал те проблемы с которыми сталкивается при работе. Я ни в коем случае сам не меняю сотрудника на его рабочем месте и не стремлюсь выполнять за него его функции. Моя практика показывает, что при таком подходе очень часто "за деревьями пропадает лес". Ведь мне нужно сделать систему не так, чтобы мне было удобно на ней работать, а так, чтобы было удобнее сотруднику, который будет работать с софтом.
Если речь идет о тиражируемой программе, направленной на решение тех или иных задач — то обязательно вхожу в контакт с представителями того круга пользователей, которые будут это использовать, знакомлюсь с их реальной работой.
4) Беру таймаут. За это время стараюсь у себя в голове сложить общий контур продукта, который следует получить. Делаю первый набросок бизнес-процессов и ТЗ
5) В процессе самостоятельной работы обычно появляются дополнительные вопросы к Заказчику, выявляются нестыковки и неувязки в его идеях.
Естественно, формулирую и задаю новые вопросы. Причем в этот раз стараюсь задавать вопросы в форме выбора одной из альтернатив:

Вы хотите ...?
Это можно решить способом ... . При этом будут следующие последствия ...
Это можно решить способом ... . При этом ...
...
Какой способ решения проблемы вы выберите и почему ?

Вы хотите ...? Но это приведет к ... Вы готовы к этому и что по этому поводу думаете?

Вы хотите ...? Но возможно альтернативное решение ... ? Оно Вас не устраивает ? Почему ?

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

6) Готовлю первый вариант ТЗ и постановки для Заказчика. Причем стараюсь не писать голый текст из предложений типа
"Программа должна ..."
А стараюсь, чтобы из текста точно было видно:
— какими способами будет решена задача и к каким это приведет последствиям;
— какова будет общая модель бизнес-процессов на предприятии после внедрения софта;
— какие возникнут орг вопросы (например, по перераспределению функций между персоналом) и как их рекомендуется решить;
— как будет выглядеть будущий софт с точки зрения пользовательских сценариев. При этом не ленюсь приложить макеты ключевых скриншотов, нарисованных, например в Visio;
— в чем будет изюминка будущего софта, его отличие от конкурентов, преимущества и недостатки (если они прогнозируются, то об этом следует говорить обязательно) по рынку;
— в каких вопросах могут потенциально возникнуть "неучтенные обстоятельства" и как локализовать зону их возникновения, с тем, чтобы когда они возникнут, это было бы мелкой неприятностью, а не большой проблемой.
Причем там, где возможны альтернативные решения, то их обязательно следует указать с пояснением цены выбора (необязательно денежной, но и орг цены, затраты дополнительных ресурсов на разработку и т.п.) того или иного пути.
7) Получается довольно объемный материал. Я его разбиваю на части и начинаю согласовывать с Заказчиком.
С руководителями Заказчика следует в первую очередь согласовывать основной контур бизнес процессов, орг вопросы, а также общие характеристики продукта и цену их реализации
От сотрудников, деятельность которых предполагается автоматизировать, стремлюсь получить информацию о том, все ли учтено, и насколько удобна для них предполагаемая модель пользовательских сценариев.
От маркетологов — оценку о месте будущего продукта на рынке в перспективе.
и т.д.
Причем, беседуя с руководителями высокого уровня Заказчика стараюсь уже заручиться предварительным мнением сотрудников более низкого уровня.

В итоге итерационного повторения шагов 5,6 и 7 и появляется окончательное ТЗ и постановка. И уже не так важно, кто будет их окончательным автором, я сам или представитель Заказчика. Важно, чтобы все необходимые действия были проведены, результаты понятны обеим сторонам, согласованы и утверждены ими.
Я здесь не упомянул консультации с программистами. Но я часто обхожусь без них в силу того, что сам являюсь программистом довольно высокого уровня с большим опытом решения разных задач, который постоянно пополняю. Поэтому работу программиста я в первую очередь примериваю на себя. В большинстве случаев этого хватает.
Конечно, если я встречаюсь с задачей из области, в которой не очень компетентен, то обязательно консультируюсь со специалистами, которые будут ее решать на этапах 6 и 7. В этом случае я веду параллельный материал, в котором ТЗ и постановка представлена с точки зрения специалистов, которые будут это реализовывать и таким образом согласовываю его с ними.

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

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

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

Не должно оставаться ощущения, что чего-то недоделал, что какие-то вещи можно сделать еще лучше. Если такое ощущение у меня остается, то я просто продолжаю работу до прояснения, либо записываю ситуацию, которая вызывает такие ощущения в будущие "непредсказуемые обстоятельства" и думаю, как ее локализовать, с тем, чтобы переделки и доделки вызывали минимальные затраты времени и сил.

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

Более конкретные рекомендации можно дать только на практике при решении конкретной задачи.

Надеюсь, я ответил на Ваш вопрос.

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

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

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

--
aga

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

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

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

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

Здравствуйте, Андрей Галюзин, Вы писали:

АГ>Есть изменения и ИЗМЕНЕНИЯ и как показывает практика первых много больше, чем вторых. Хотя если указать в ТЗ расположение всех элементов на формах, цвет иконок и пр, тогда, возможно, их станет меньше, но полностью от них избавиться невозможно. Очень сложно (а на мой взгляд невозможно) создать хороший продукт без мнения пользователей, а оно может появиться только, когда продукт выходит в альфы. Так что изменения будут всегда и надо с этим смириться.
Конечно изменения будут, но они должны быть или запланированными или их должно не быть Насчет невозможности отразить все в спецификации я согдасен, именно поэтому она должна начинаться словами: "Все что не указано явно в этой спецификации может быть реализовано на усмотрение разработчика". Например заказчик подразумевал виндовые окошки, а мы ему сделали HTML диалоги. Это плохо если заказчик ненавидит HTML или неважно, если ему важна только функциональность, но формально разработчик вправе это сделать.

SMS> 3) Если идет речь об автоматизации функций сотрудника, то я обязательно провожу 1 — 2 дня рядом с сотрудником и просто наблюдаю за тем, что он делает, не задавая никаких вопросов.

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

Пожалуй, это единственное с чем я не согласен в вашей методике.

SMS> Надеюсь, я ответил на Ваш вопрос.

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

Вопрос1: Насколько детально прорбатывается постановка задачи? Например, при описании счет-фактуры, описываете ли вы все поля, какие там должны быть, их примерные размерности и типы?

Вопрос2: доводилось ли вам делать аналитику для удаленных заказчиков, когда просто невозможно изучить бизнесс-процессы на месте и в полном объеме?

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

A_>Здравствуйте, Андрей Галюзин, Вы писали:

АГ>>Есть изменения и ИЗМЕНЕНИЯ и как показывает практика первых много больше, чем вторых. Хотя если указать в ТЗ расположение всех элементов на формах, цвет иконок и пр, тогда, возможно, их станет меньше, но полностью от них избавиться невозможно. Очень сложно (а на мой взгляд невозможно) создать хороший продукт без мнения пользователей, а оно может появиться только, когда продукт выходит в альфы. Так что изменения будут всегда и надо с этим смириться.
A_>Конечно изменения будут, но они должны быть или запланированными или их должно не быть Насчет невозможности отразить все в спецификации я согдасен, именно поэтому она должна начинаться словами: "Все что не указано явно в этой спецификации может быть реализовано на усмотрение разработчика". Например заказчик подразумевал виндовые окошки, а мы ему сделали HTML диалоги. Это плохо если заказчик ненавидит HTML или неважно, если ему важна только функциональность, но формально разработчик вправе это сделать.

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

Ac> Конечно изменения будут, но они должны быть или запланированными или их должно не быть

Вот об невозможности этой ситуации я и говорил. Лучше все же планировать и проектировать с разчетом на возможные изменения.

[skipped]

--
aga

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

S> Описанная проблема относится к категории проектных рисков, а риски нужно разрешать как можно быстреее. Вообще говоря, что мешает уведомить заказчика о принятых технических решениях? Что мешает сперва разработать и показать заказчику прототип системы? Тем более что при групповой работе прототипирование является полезным и для самой команды.
Можно, но это не избавит от проблем при приемке пректа, если это не будет задокументировано Просто некоторые конторы пытаются реализовать любой каприз заказчика. Например я помню как делали закрытие любого окна по нажатию ESC. Естественно никакого базового оконного класса не было. При приемке проекта было сказано: "Кнопочка ESC это хорошо, но это мелоч, а вот чего у вас экспорт данных глючит?". И в этом случае уже формально прав заказчик

S> Кстати, XP-шная практика выполнения частых сборок проекта и демонстрация промежуточных результатов заказчику работает великолепно. Нечего до альфы тянуть, как только реализована хоть какая-то ключевая фича — показать заказчику и поинтересоваться мнением.
Да какие проблемы, я видел многих, реально заинтересованных в результате заказчиков, которые специально выделяли персонал для того чтобы держать руку на пульсе проекта, ездить, смотреть промежуточные сборки. Или заказчик должен быть готов включить затраты на такого человека в стоимость проекта.

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

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


SMS>> 3) Если идет речь об автоматизации функций сотрудника, то я обязательно провожу 1 — 2 дня рядом с сотрудником и просто наблюдаю за тем, что он делает, не задавая никаких вопросов.

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

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

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

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

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

S>Вопрос1: Насколько детально прорбатывается постановка задачи?

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

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

S>Например, при описании счет-фактуры, описываете ли вы все поля, какие там должны быть, их примерные размерности и типы?

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

S>Вопрос2: доводилось ли вам делать аналитику для удаленных заказчиков, когда просто невозможно изучить бизнесс-процессы на месте и в полном объеме?

Доводилось. В этом случае я стараюсь работать по аналогии с теми предприятиями, задачами, компаниями, с которыми я знаком, либо могу до них дотянуться.
Я обычно:
1) Слушаю и уточняю начальные пожелания Заказчика (в письмах)
2) Излагаю свое видение вопроса (на основе пожеланий Заказчика и аналогий), указываю критические точки (трудно реализуемые моменты) пожеланий Заказчика, предлагаю свое видение разрешения проблем и спрашиваю его, с чем он соглачен, а с чем нет.
3) Получаю ответ, обдумываю...

И далее повторяю шаги 2, 3 до тех пор, пока не наберется достаточный материал, чтобы описать целостную картину. После чего делаю ТЗ и/или постановку и согласовываю и т.д.

Общие принципы меняются не сильно.

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

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

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

<<SKIPPED>>

И каковы временные затраты на такой детальный анализ?
Особенно, если система большая и предметная область закрытая (к примеру, узкоспециализированная корпоративная система)? И как ты будешь изучать опыт конкурентов, если их разработки — коммерческая тайна?

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

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

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

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

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

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

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

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

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

M><<SKIPPED>>

M>И каковы временные затраты на такой детальный анализ?

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

M>Особенно, если система большая и предметная область закрытая (к примеру, узкоспециализированная корпоративная система)? И как ты будешь изучать опыт конкурентов, если их разработки — коммерческая тайна?

Очень большое заблуждение, что "коммерческая тайна" скрывает все секреты. Это далеко не так.

1) В любой области знаний и деятельности существуют различного рода статьи и исследования, тестовые и открытые системы, на основе идей которых и строятся системы, представляющие так называемую "коммерческую тайну". Причем системы с "коммерческой тайной" далеко не всегда лучший вариант таких систем.
2) Публикуются материалы к семинарам и форумам, на которых часто докладывают руководители отделов фирм, использующих "закрытые" системы. Из их сообщений много чего можно почерпнуть
3) Можно найти людей среди разработчиков (особенно в Москве), которые соприкасались с подобной системой. В свидетели они не пойдут, но в приватном разговоре многие аспекты картины прояснят
4) Термин "коммерческая тайна" относится обычно только к "вертикальным" системам. Например, к подразделениям одной и той же корпорации, отрасли.
Но практически всегда (если речь не идет, например, о таких уникальных предприятиях, как Газпром или Норильский Никель) существует предприятие, имеющее подразделение, корреллирующее с темой будущей разработки, которое не считает свое положение ни коммерчески закрытым, ни тайным
5) Сами разработчики подобных систем обычно не сильно скрывают это и публикуют описание технологий, скриншотов и т.п.

и т.д.

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

Нужно просто уметь работать с информацией.

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

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

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

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

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

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

M>Ладно. Спасибо за точку зрения. Хоть я с ней и не согласен, но, возможно,
M>у вас действительно столь успешный опыт. Надеюсь, смогу когда-нибудь так же смотреть
M>на все в розовом цвете. Успехов.

Спасибо.

Все очень просто. Сформулируйте для себя, как Вы ХОТИТЕ работать, постоянно помните об этом и на практике постоянно стремитесь именно к этому, по возможности, не в ущерб текущей работе, разумеется, но НЕУКЛОННО. И постепенно, со временем, конечно, у Вас все начнет получаться. Я это говорю по собственному опыту. И тогда Вы не будете считать, что я вижу все в розовом свете. Кстати, я тоже когда-то занимался в основном заплатками и считал, что без этого никак.Но однажды мне это надоело... Успехов.

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

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

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

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

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

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

S>>Например, при описании счет-фактуры, описываете ли вы все поля, какие там должны быть, их примерные размерности и типы?

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

Ох уже мне эта фразочка "ничего меняться не будет"... Категорически заявляю: ничего не меняется только в мертвом бизнесе. То есть вероятность, что что-то изменится уже в ходе проектирования/разработки есть всегда. Согласен, многие вещи можно предусмотреть (тот же случай с НДС). Но чтобы предусмотреть все... В такое я не верю. Вот такой я, блин, пессимист

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

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

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


S>>Вопрос2: доводилось ли вам делать аналитику для удаленных заказчиков, когда просто невозможно изучить бизнесс-процессы на месте и в полном объеме?

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

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

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

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

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

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

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

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

S>Хм. Интервью с непосредственным исполнителем врядли стоит начинать до того, как свое видение по существующему workflow выскажет руководитель.

Разумеется. Ведь инициатива по workflow исходит то руководства. Но следует иметь в виду, что руководитеьл всегда очень хорошо знает, что ему нужно получить и в какие сроки. Вопрос "как ?" его обычно не очень волнует. А ведь именно от ответа на этот вопрос зависит удобство софта и то, что при работе с ним не понадобится, например Excel.

S>А хорошо бы еще и с должностной инструкцией познакомиться.
Должностные инструкции составляют руководители. Они обычно очень хорошо отвечают на вопрос "что ?". Но на вопрос "как ?" ответ формируется часто из неких теоретических представлений руководства, которые реальным исполнителям приходится в жизни дополнять и развивать.

S>Тогда исполнителю хитрить будет намного сложнее.
Я не очень понимаю, зачем нужно разгадывать какие-то хитрости исполнителя, устраивать ему различные допросы, когда можно всего этого избежать всего лишь внимательным наблюдением со стороны. Мне кажется, что так намного проще и надежнее.

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

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

S>>>Например, при описании счет-фактуры, описываете ли вы все поля, какие там должны быть, их примерные размерности и типы?

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

S>Ох уже мне эта фразочка "ничего меняться не будет"... Категорически заявляю: ничего не меняется только в мертвом бизнесе. То есть вероятность, что что-то изменится уже в ходе проектирования/разработки есть всегда. Согласен, многие вещи можно предусмотреть (тот же случай с НДС). Но чтобы предусмотреть все... В такое я не верю. Вот такой я, блин, пессимист

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

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

А почему, например, кодировку групп товаров лучше определять заранее?
Дело в том, что если применять ГОСТ- овскую кодировку, то вы получите одну структуру данных для хранения иерархий товаров (просто линейная таблица). Если же применять стандартный SQL — подход, то структура данных будет совершенно иной (добавится таблица перекрестных ссылок, одна ли несколько). Не нужно, я думаю, пояснять, насколько серьезно это повлияет на разработку, на трудозатраты, сроки, интерфейсы ?

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

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

S>Если ТЗ не содержит деталей по атрибутам сущностей, которые предстоит реализовать, то этого ТЗ вполне может хватить для рассчета сроков/стоимости, но не хватит для начала проектирования. То есть уточннение деталей вы делегируете программистам, так?

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

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

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

Роль — разработка (определение и контроль реализации) функциональной модели софта. В том числе: обследование Заказчика, согласование с Заказчиком ТЗ и постановок, согласование функциональной части с программистами (по возможности реализации и по срокам), мониторинг разработки с точки зрения функциональной части, раннее выявление "непредвиденных обстоятельств" и согласование с ПМ и Заказчиком способов их устранения, первичная приемка софта от программистов, первичное внутреннее тестирование (или организация такового группой тестировщиков),
пользовательская документация (или организация разработки документации специальной группой),передача софта Заказчику совместно с программистами, организация совместно с программистами поддержки и т.д.

S>>>Вопрос2: доводилось ли вам делать аналитику для удаленных заказчиков, когда просто невозможно изучить бизнесс-процессы на месте и в полном объеме?

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

S>Ох, что-то слабо я верю в ценность такого подхода. Ну про коммерческую тайну тут уже говорили, я приведу другой пример. Когда-то я работал в одной очень крупной торговой кампании с очень неплохим уровнем автоматизации бизнес-процессов. Однажды привез я из другого филиала программный комплекс по приему поставок с применением терминалов сбора данных. Систему это я в деталях изучил, беседуя с авторами, с практическими примерами, и с ходу заявил своему директору, что мы сможем внедрить её as is.

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

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

S>Да что там, спросите любого 1С-овца, который по клиентам бегает, и он расскажет вам, насколько отличаются подходы в организации учета, в решении одной и той же задачи в разных фирмах.

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

Здравствуйте, Андрей Галюзин, Вы писали:


АГ>Есть изменения и ИЗМЕНЕНИЯ и как показывает практика первых много больше, чем вторых. Хотя если указать в ТЗ расположение всех элементов на формах, цвет иконок и пр, тогда, возможно, их станет меньше, но полностью от них избавиться невозможно. Очень сложно (а на мой взгляд невозможно) создать хороший продукт без мнения пользователей, а оно может появиться только, когда продукт выходит в альфы. Так что изменения будут всегда и надо с этим смириться. А вот переписывания всего проекта можно избежать, для этого есть шаблоны, проектирование и достаточное количество литературы (а также форумов .

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