Здравствуйте, 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С-овца, который по клиентам бегает, и он расскажет вам, насколько отличаются подходы в организации учета, в решении одной и той же задачи в разных фирмах.

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