В вакансиях часто стало встречаться требование
"Опыт промышленной разработки"?
Предложение обсудить этот термин, где проходит грань между "промышленной" и
"непромышленной".
Лично у меня вариантов нет, я вообще не знаю, что _точно_ под этим термином
подразумевается.
Здравствуйте, маген, Вы писали:
М>В вакансиях часто стало встречаться требование М>"Опыт промышленной разработки"?
М>Предложение обсудить этот термин, где проходит грань между "промышленной" и М>"непромышленной".
Грань может быть зыбкой и о ней нет смысла рассуждать.
Обычно под этим понимают разработку продукта в команде,
разработка которого проходила более менее осознанно по некоторому процессу.
Ну например должно быть в неком виде планирование, управление требованиями, проектирование,
осознанное тестирование и координация все этого дела...
Мне кажется, что если разработанная тобой программа крутится в режиме 24*7 в десятке стран, на 5000 компьютерах, то можно смело говорить об опыте участия в промышленной разработке. То есть, программы, написанные "для себя", "для нашего банка", "для бухгалтерии" и промышленная разработка это немного разное. Может быть это имеется в виду под "промышленной разработкой"?
Здравствуйте, маген, Вы писали:
М>В вакансиях часто стало встречаться требование М>"Опыт промышленной разработки"?
М>Предложение обсудить этот термин, где проходит грань между "промышленной" и М>"непромышленной". М>Лично у меня вариантов нет, я вообще не знаю, что _точно_ под этим термином М>подразумевается.
это означает "мы вам мало заплатим и будем долбить мозг на собеседовании"
Здравствуйте, маген, Вы писали:
М>В вакансиях часто стало встречаться требование М>"Опыт промышленной разработки"?
М>Предложение обсудить этот термин, где проходит грань между "промышленной" и М>"непромышленной". М>Лично у меня вариантов нет, я вообще не знаю, что _точно_ под этим термином М>подразумевается.
Под этим термином подразумевается, что эту компанию нужно обходить стороной. Потому что после "промышленного" программирования появится "уровень профессионализма" и прочая не формулируемая белиберда.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, маген, Вы писали:
М>В вакансиях часто стало встречаться требование М>"Опыт промышленной разработки"?
М>Предложение обсудить этот термин, где проходит грань между "промышленной" и М>"непромышленной". М>Лично у меня вариантов нет, я вообще не знаю, что _точно_ под этим термином М>подразумевается.
В адекватных конторах -- умение слушаться, не выпендриваться и не срывать сроки более чем в два раза
Здравствуйте, маген, Вы писали:
М>В вакансиях часто стало встречаться требование М>"Опыт промышленной разработки"?
М>Предложение обсудить этот термин, где проходит грань между "промышленной" и М>"непромышленной". М>Лично у меня вариантов нет, я вообще не знаю, что _точно_ под этим термином М>подразумевается.
Могу предположить, что это опыт разработки приложений за деньги.
Можно же и 10 лет програмировать свою мегаигруху, но это врядли даст вам адекватную оценку и направление как програмиста.
Здравствуйте, маген, Вы писали:
М>В вакансиях часто стало встречаться требование М>"Опыт промышленной разработки"? М>Предложение обсудить этот термин, где проходит грань между "промышленной" и М>"непромышленной".
Не стоит так трепетно относиться к текстам резюме и вакансий.
Составитель вакансии мог написать это просто так, для пущей серъезности, и сам не знать, что это значит. Не редкость. Может означать «нужен человек с опытом, студентов и непризнанных гениев-одиночек просьба не беспокоить».
Здравствуйте, маген, Вы писали:
М>Предложение обсудить этот термин, где проходит грань между "промышленной" и М>"непромышленной".
Бывает разработка академическая, когда достаточно показать принципиальную возможность чтобы вставить красивые графики в статью/отчет по гранту/диссертацию/монографию. Бывает учебная, когда процесс важнее результата, а конечной целью становятся знания. Бывает хоббийная разработка, когда критерии к результату определяет сам любитель, исходя из своего видения прекрасного. Бывает и промышленная разработка, когда требования к результату, а зачастую и к процессу, определяет сторонний человек.
Требуя у соискателя опыта промышленной разработки, обычно ожидают, что он
будет делать то, что ему говорят, проявляя при этом разумную степень инициативы;
будет подчиняться сторонним ограничениям, даже если они кажутся ему бессмысленными;
т.е. понимает и принимает правила игры.
Здравствуйте, Miroff, Вы писали:
M>Требуя у соискателя опыта промышленной разработки, обычно ожидают, что он M> будет делать то, что ему говорят, проявляя при этом разумную степень инициативы; M> будет подчиняться сторонним ограничениям, даже если они кажутся ему бессмысленными; M>т.е. понимает и принимает правила игры.
У меня вот всегда были проблемы с этим пунктом. Ибо всякий раз, когда я делал что-то, не понимая смысла, выходила какая-то фигня, и потом она сто раз переделывалась. Так что я предпочитаю провести дополнительные полчаса на митинге, выяснив, зачем это нужно. Потому что любое требование, любое ограничение имеет причину — и знать её всегда очень полезно.
Здравствуйте, koandrew, Вы писали:
K>Потому что любое требование, любое ограничение имеет причину — и знать её всегда очень полезно.
До причин обычно можно без особых проблем добраться.
То, до чего за пол часа можно докопаться — это вообще скорей всего мелочь.
Но вопрос не в этом.
Вопрос в том, устроит ли тебя, к примеру, требование использовать табы вместо пробелов (или наоборот)
со ссылкой на стандарт кодирования или с каждым новым работником надо тратить дни на споры
Здравствуйте, bkat, Вы писали:
B>Вопрос в том, устроит ли тебя, к примеру, требование использовать табы вместо пробелов (или наоборот) B>со ссылкой на стандарт кодирования или с каждым новым работником надо тратить дни на споры
Вообще-то лучше тратить дни на споры или просто не брать таких людей.
Если вы ставите скобку так{ а я ставлю так
{
, то это может говорить о очень глубоких психологических различиях в команде. Какой смысл брать себе на голову проблему?
Здравствуйте, Miroff, Вы писали:
M>Требуя у соискателя опыта промышленной разработки, обычно ожидают, что он M> будет делать то, что ему говорят, проявляя при этом разумную степень инициативы; M> будет подчиняться сторонним ограничениям, даже если они кажутся ему бессмысленными; M>т.е. понимает и принимает правила игры.
А скажем, для "академической" разработки это не применимо?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, bkat, Вы писали:
B>До причин обычно можно без особых проблем добраться. B>То, до чего за пол часа можно докопаться — это вообще скорей всего мелочь. B>Но вопрос не в этом. B>Вопрос в том, устроит ли тебя, к примеру, требование использовать табы вместо пробелов (или наоборот) B>со ссылкой на стандарт кодирования или с каждым новым работником надо тратить дни на споры
Мне не доводилось работать в командах с большой ротацией (потому что я сознательно стараюсь обходить такие конторы стороной), так как у этого явления тоже есть причины, и я не хочу испытать действие этих причин на себе. Обычно к началу проекта команда уже сформирована, и посидеть разок и договориться о стиле не проблема. Кроме того, мне в общем-то всё равно, пробелы там используются или табы, но мне, например, не нравится привычка пихать несколько классов в один файл (потому что я ищу исходный код класса, "выводя" имя файла и расположение из его названия, посему отход от данного правила банально усложняет мне работу).
Bottom line — communication is a key, обо всём можно договориться. Но не о том сейчас речь. Я имею в виду ситуации, когда меня просят реализовать "кнопку, по нажатию на которую покажется сообщение ...", не объясняя того, зачем эта кнопка нужна и какие тут возможны use-case'ы. Иначе говоря, когда мне объясняют, как надо сделать, вместо того, что надо сделать — с первым при наличии второго я и сам справлюсь...
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, bkat, Вы писали:
B>>Вопрос в том, устроит ли тебя, к примеру, требование использовать табы вместо пробелов (или наоборот) B>>со ссылкой на стандарт кодирования или с каждым новым работником надо тратить дни на споры
FDS>Вообще-то лучше тратить дни на споры или просто не брать таких людей. FDS>Если вы ставите скобку так{ а я ставлю так FDS>{ FDS>, то это может говорить о очень глубоких психологических различиях в команде. Какой смысл брать себе на голову проблему?
На то и испытательный срок. На интервью все мелочи повседневной рутины все равно не обсудить.
Если новый человек в принципе не готов подстроиться под команду, то он и сам уйдет.
Человек с опытом довольно быстро перестоится и не будет думать
о глубоких психологических различиях в команде.
Ну либо через годик-два после мягкой, но эффективной обработки других,
перетянет других на свою сторону (стандарт кодирования будет изменен )
Но то был всего лишь пример.
В целом, готовность идти на компромиссы — это весьма и весьма важно.
Здравствуйте, koandrew, Вы писали:
K>Bottom line — communication is a key, обо всём можно договориться. Но не о том сейчас речь. Я имею в виду ситуации, когда меня просят реализовать "кнопку, по нажатию на которую покажется сообщение ...", не объясняя того, зачем эта кнопка нужна и какие тут возможны use-case'ы. Иначе говоря, когда мне объясняют, как надо сделать, вместо того, что надо сделать — с первым при наличии второго я и сам справлюсь...
Хм...
Ну дак спеки на что?
Они, если грамотно написаны, то как раз в идеале и описывают что надо сделать,
а не то, как это надо делать.
Спеки естественно должны "ревьютиться" и в том числе и разработчиками.
Очень важная, кстати, часть того, что я понимаю под "промышленной разработкой".
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Miroff, Вы писали:
M>>Требуя у соискателя опыта промышленной разработки, обычно ожидают, что он M>> будет делать то, что ему говорят, проявляя при этом разумную степень инициативы; M>> будет подчиняться сторонним ограничениям, даже если они кажутся ему бессмысленными; M>>т.е. понимает и принимает правила игры.
ГВ>А скажем, для "академической" разработки это не применимо?
Для академической правила мягче.
<Подпись удалена модератором>
Решение не принято - обсуждаем. Принято - исполняем.
M>>Требуя у соискателя опыта промышленной разработки, обычно ожидают, что он M>> будет делать то, что ему говорят, проявляя при этом разумную степень инициативы; M>> будет подчиняться сторонним ограничениям, даже если они кажутся ему бессмысленными; M>>т.е. понимает и принимает правила игры.
K>У меня вот всегда были проблемы с этим пунктом. Ибо всякий раз, когда я делал что-то, не понимая смысла, выходила какая-то фигня, и потом она сто раз переделывалась. Так что я предпочитаю провести дополнительные полчаса на митинге, выяснив, зачем это нужно. Потому что любое требование, любое ограничение имеет причину — и знать её всегда очень полезно.
абсолютно верно.
Кстати, не вижу здесь никакого противоречия со словами Miroff — если что-то непонятно всегда можно спросить. И зачастую получить ответ.
Важно понять одно — пока решение не принято, можно (и нужно) предлагать варианты, обсуждать что угодно и до хрипоты отстаивать свое мнение — это все ОК. После того как поспорили-обсудили-оценили плюсы-минусы и так или иначе, но приняли решение что "делаем так" — дальше колебания и саботаж в пользу альтернативных вариантов уже становятся очень нежелательны. Даже если они иной раз действительно в чем-то оптимальнее. Поздно. Всему свое время.
PS Даже если ты с чем-то несогласен — сделай как решили, причем не саботируй, приложи все усилия — а жизнь покажет кто был прав. Тем более, что не составляет труда для любителей post-mortem разборок отписать свои соображения в процессе обсуждения (или сразу по его итогам) — и потом аппеллировать к тому какой ты был провидец. Суть в том, что все разборки должны быть отложены до подходящего момента — когда ввязались в бой уже поздно выяснять какой умник в штабе нас сюда отправил, надо выполнять задачу, а не выбрасывать белый флаг. PPS Полезно помнить, что часто к цели можно добраться тысячью дорог.
... << RSDN@Home 1.2.0 alpha 4 rev. 1325>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
В дополнение к сказанному — промышленная разработка это еще и доведение кода до состояния, когда его можно отдать заказчику/упаковать в коробку. Т.е. в нем нет "тут не работает, тут недоделано, тут надо подрихтовать, а тут рыбу заворачивали". К сожалению, очень многие начинающие разработчики не понимаю, как долог путь от рабочего концепта до промышленного решения.
... << RSDN@Home 1.2.0 alpha 4 rev. 1324 on Windows 7 6.1.7600.0>>
Здравствуйте, bkat, Вы писали:
K>>Bottom line — communication is a key, обо всём можно договориться. Но не о том сейчас речь. Я имею в виду ситуации, когда меня просят реализовать "кнопку, по нажатию на которую покажется сообщение ...", не объясняя того, зачем эта кнопка нужна и какие тут возможны use-case'ы. Иначе говоря, когда мне объясняют, как надо сделать, вместо того, что надо сделать — с первым при наличии второго я и сам справлюсь...
B>Хм... B>Ну дак спеки на что?
Спеки — это просто один из способов коммуникации. Это не вещь в себе, не самоцель и не единственный способ коммуникации. Такой подход имеет свои плюсы, имеет свои минусы и уж точно не является единственным и не является панацеей.
Здравствуйте, AndrewVK, Вы писали:
AVK>В дополнение к сказанному — промышленная разработка это еще и доведение кода до состояния, когда его можно отдать заказчику/упаковать в коробку. Т.е. в нем нет "тут не работает, тут недоделано, тут надо подрихтовать, а тут рыбу заворачивали". К сожалению, очень многие начинающие разработчики не понимаю, как долог путь от рабочего концепта до промышленного решения.
Что-то я не пойму. А как тогда быть с той частью IT-индустрии (т.е. — промышленности), которая занимается разработкой заказного ПО с единичными инсталляциями и непрерывным циклом доработки? Это, типа, "не промышленная" разработка?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, маген, Вы писали:
AVK>В дополнение к сказанному — промышленная разработка это еще и доведение кода до состояния, когда его можно отдать заказчику/упаковать в коробку.
Выходит гугл не занимается промышленной разработкой?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Что-то я не пойму. А как тогда быть с той частью IT-индустрии (т.е. — промышленности), которая занимается разработкой заказного ПО с единичными инсталляциями и непрерывным циклом доработки? Это, типа, "не промышленная" разработка?
Почему ты так решил? Код доводится до состояния, когда он применяется для автоматизации реальной деятельности, так что он вполне промышленный.
... << RSDN@Home 1.2.0 alpha 4 rev. 1324 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Что-то я не пойму. А как тогда быть с той частью IT-индустрии (т.е. — промышленности), которая занимается разработкой заказного ПО с единичными инсталляциями и непрерывным циклом доработки? Это, типа, "не промышленная" разработка?
AVK>Почему ты так решил? Код доводится до состояния, когда он применяется для автоматизации реальной деятельности, так что он вполне промышленный.
Я просто не пойму, где ключевые различия промышленного и непромышленного подхода, грубо говоря. Неработающую программу даже студент в качестве курсовика не может подсунуть (как правило).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Я просто не пойму, где ключевые различия промышленного и непромышленного подхода, грубо говоря. AVK>Если ты ищешь четкую и однозначную границу, то ее нет.
Упс. А как же тогда выставлять требования к вакансии? Если даже чёткой границы области определения нет?
ГВ>> Неработающую программу даже студент в качестве курсовика не может подсунуть (как правило). AVK>Работающая программа — это необходимое, но никак не достаточное требование.
Отлично, а что тогда достаточные требования?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>> Неработающую программу даже студент в качестве курсовика не может подсунуть (как правило). AVK>>Работающая программа — это необходимое, но никак не достаточное требование.
ГВ>Отлично, а что тогда достаточные требования?
имхо, наличие не только готовой, даже не полностью, но готовой на некотором этапе системы, которую будут и\или будут и уже используют в "боевом" режиме т.е. с реальными данными, для реальной автоматизации, а не некоторый теоретический продукт. Причем проблемы, которые возникают в уже внедренной и используемой системы решаются совсем по-другому, вспомнить хотя бы решение проблем безопасности, падения, недоработок и т.д. в Windows, Office, 1C и подобных. Именно опыт разработки и поддержки уже внедренных систем наверное и подразумевается в такой вакансии.
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Упс. А как же тогда выставлять требования к вакансии? Если даже чёткой границы области определения нет? AVK>Вот так и выставлять. А что тебя удивляет?
Не понятно, как определять соответствие. Разве что по самоназванию.
AVK>У требования вроде "знание С++" тоже четкой границы нет.
Очень даже есть. И легко проверяется.
ГВ>>Отлично, а что тогда достаточные требования? AVK>Количество глюков на приемлемом уровне, отсутствие грубых недоделок, хорошее качество кода и много чего еще.
Тогда это просто опыт разработки программ, которые были переданы в эксплуатацию реальным пользователям. Вроде, ничем не отличается от любой другой коллективной разработки на заказ.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, RonWilson, Вы писали:
ГВ>>Отлично, а что тогда достаточные требования?
RW>имхо, наличие не только готовой, даже не полностью, но готовой на некотором этапе системы, которую будут и\или будут и уже используют в "боевом" режиме т.е. с реальными данными, для реальной автоматизации, а не некоторый теоретический продукт. Причем проблемы, которые возникают в уже внедренной и используемой системы решаются совсем по-другому, вспомнить хотя бы решение проблем безопасности, падения, недоработок и т.д. в Windows, Office, 1C и подобных. Именно опыт разработки и поддержки уже внедренных систем наверное и подразумевается в такой вакансии.
Хм. Но это именно опыт "внедрения и поддержки". При чём тут отдельная категория "промышленности"?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Хм. Но это именно опыт "внедрения и поддержки". При чём тут отдельная категория "промышленности"?
внедрять и поддерживать можно разные по масштабам и ориентированные на разные рынки системы, можно иметь такой опыт для какого-нибудь плеера, ошибка в котором в принципе обидное дело, но исправляется путем выкладывания нового exe-шника, или ошибки в системе бухгалтерского учета, в результате которых люди попросту не смогут работать, а то еще хуже. это конечно мое имхо, но как-то так.
Вот кстати определение из курса управления качеством, в ней нет выделения такого, что вот эта система — промышленная а это нет, это просто определение технологического процесса:
Промышленная разработка программного обеспечения как часть промышленной разработки сложных систем — высокотехнологичный процесс, в который вовлечено множество различающихся по численности, сфере деятельности и квалификации коллективов разработчиков. Одна из основных задач при совместной работе большого количества разработчиков или их коллективов: обеспечение единой схемы работы, позволяющей планировать выполнение работ, обеспечивать целостность и непротиворечивость различных узлов системы, а также давать гарантии соответствия системы ожиданиям заказчика.
Здравствуйте, Геннадий Васильев, Вы писали:
AVK>>Вот так и выставлять. А что тебя удивляет?
ГВ>Не понятно, как определять соответствие. Разве что по самоназванию.
Определяется по тому, какое качество кода на выходе получается. На практике отсутствие упомянутого навыка очень хорошо видно. Даже в форуме.
AVK>>У требования вроде "знание С++" тоже четкой границы нет.
ГВ>Очень даже есть.
Нету. Потому что у каждого своя степень знания материала, с которой начинается это "знает". Кому то знания синтаксиса достаточно, а кому то и детального изучения александресковщины мало.
ГВ>>>Отлично, а что тогда достаточные требования? AVK>>Количество глюков на приемлемом уровне, отсутствие грубых недоделок, хорошее качество кода и много чего еще.
ГВ>Тогда это просто опыт разработки программ, которые были переданы в эксплуатацию реальным пользователям.
Примерно так.
ГВ> Вроде, ничем не отличается от любой другой коллективной разработки на заказ.
Зато отличается от многих опенсорсов, проектов типа RSDN@Home, академических исследований и упомянутого тобой курсача.
... << RSDN@Home 1.2.0 alpha 4 rev. 1324 on Windows 7 6.1.7600.0>>
М>Лично у меня вариантов нет, я вообще не знаю, что _точно_ под этим термином М>подразумевается.
Насколько я понимаю, под данным термином не подразумевается вообще ничего. Как ты правильно заметил, этот термин начинает появляться все чаще и чаще; однажды, может быть, кто-то что-то в него и вложил (но об этом все уже благополучно забыли), а остальным сама фраза понравилась "промышленная разработка". Реально же круто звучит? Уж однозначно круче чем "опыт разработки N лет"!
Итого: очередное модное требование, как когда-то "знание паттернов проектирования", которое было в каждом втором требовании к соискателю.
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Тогда это просто опыт разработки программ, которые были переданы в эксплуатацию реальным пользователям. AVK>Примерно так.
появилось нечто похожее на определение. По крайней мере, можно обсудить более предметно.
P.S.: В прочем, с наступающим!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Кэр, Вы писали:
Кэр>Здравствуйте, bkat, Вы писали:
K>>>Bottom line — communication is a key, обо всём можно договориться. Но не о том сейчас речь. Я имею в виду ситуации, когда меня просят реализовать "кнопку, по нажатию на которую покажется сообщение ...", не объясняя того, зачем эта кнопка нужна и какие тут возможны use-case'ы. Иначе говоря, когда мне объясняют, как надо сделать, вместо того, что надо сделать — с первым при наличии второго я и сам справлюсь...
B>>Хм... B>>Ну дак спеки на что?
Кэр>Спеки — это просто один из способов коммуникации. Это не вещь в себе, не самоцель и не единственный способ коммуникации. Такой подход имеет свои плюсы, имеет свои минусы и уж точно не является единственным и не является панацеей.
Со всем согласен, но в любом случае спеки — это стандартный подход
для описания того, что должна делать система.
Если есть проблемы внятно на бумаге сформулировать то, что хочется получить от системы,
то врядли другие способы коммуникации позволят это сделать намного лучше.
Здравствуйте, bkat, Вы писали:
K>>>>Bottom line — communication is a key, обо всём можно договориться. Но не о том сейчас речь. Я имею в виду ситуации, когда меня просят реализовать "кнопку, по нажатию на которую покажется сообщение ...", не объясняя того, зачем эта кнопка нужна и какие тут возможны use-case'ы. Иначе говоря, когда мне объясняют, как надо сделать, вместо того, что надо сделать — с первым при наличии второго я и сам справлюсь...
B>>>Хм... B>>>Ну дак спеки на что?
Кэр>>Спеки — это просто один из способов коммуникации. Это не вещь в себе, не самоцель и не единственный способ коммуникации. Такой подход имеет свои плюсы, имеет свои минусы и уж точно не является единственным и не является панацеей.
B>Со всем согласен, но в любом случае спеки — это стандартный подход B>для описания того, что должна делать система. B>Если есть проблемы внятно на бумаге сформулировать то, что хочется получить от системы, B>то врядли другие способы коммуникации позволят это сделать намного лучше.
Конкретно в контексте этой дискуссии. Вы предлагаете документировать поведение кнопки. Возможно это имеет смысл (если документ описывает общее поведение системы, и из этого однозначно понятно, что кнопка должна делать), но также вполне возможно это не имеет смысла. И дело тут не в том, что есть какие-то проблемы внятно сформулировать поведение кнопки на бумаге. Проблема в том, что дорого писать такую подробную документацию и потом поддерживать эту документацию в актуальном состоянии. Возможно гораздо проще обговорить это с ключевыми людьми, если есть вопросы, и написать реализацию.
Здравствуйте, Кэр, Вы писали:
Кэр>Здравствуйте, bkat, Вы писали:
K>>>>>Bottom line — communication is a key, обо всём можно договориться. Но не о том сейчас речь. Я имею в виду ситуации, когда меня просят реализовать "кнопку, по нажатию на которую покажется сообщение ...", не объясняя того, зачем эта кнопка нужна и какие тут возможны use-case'ы. Иначе говоря, когда мне объясняют, как надо сделать, вместо того, что надо сделать — с первым при наличии второго я и сам справлюсь...
B>>>>Хм... B>>>>Ну дак спеки на что?
Кэр>>>Спеки — это просто один из способов коммуникации. Это не вещь в себе, не самоцель и не единственный способ коммуникации. Такой подход имеет свои плюсы, имеет свои минусы и уж точно не является единственным и не является панацеей.
B>>Со всем согласен, но в любом случае спеки — это стандартный подход B>>для описания того, что должна делать система. B>>Если есть проблемы внятно на бумаге сформулировать то, что хочется получить от системы, B>>то врядли другие способы коммуникации позволят это сделать намного лучше.
Кэр>Конкретно в контексте этой дискуссии. Вы предлагаете документировать поведение кнопки. Возможно это имеет смысл (если документ описывает общее поведение системы, и из этого однозначно понятно, что кнопка должна делать), но также вполне возможно это не имеет смысла. И дело тут не в том, что есть какие-то проблемы внятно сформулировать поведение кнопки на бумаге. Проблема в том, что дорого писать такую подробную документацию и потом поддерживать эту документацию в актуальном состоянии. Возможно гораздо проще обговорить это с ключевыми людьми, если есть вопросы, и написать реализацию.
Дискуссия будет конкретна на конкретном проекте
А вообще, да я предлагаю документировать поведение кнопки.
Вернее сформулировать функцию системы, которая подразумевается.
Будет ли это кнопка или пункт меню или еще что-либо — это уже, кстати, больше решение.
И не такая уж и нерешаемая задача, которая требует не так уж и много людей и ресурсов.
Обговаривать с ключевыми людьми все равно придется.
Вопрос только в том, останется ли после обсуждений только дым в курилке
или будет что-то конкретное в документе.
Здравствуйте, bkat, Вы писали:
B>А вообще, да я предлагаю документировать поведение кнопки. B>Вернее сформулировать функцию системы, которая подразумевается. B>Будет ли это кнопка или пункт меню или еще что-либо — это уже, кстати, больше решение. B>И не такая уж и нерешаемая задача, которая требует не так уж и много людей и ресурсов. B>Обговаривать с ключевыми людьми все равно придется. B>Вопрос только в том, останется ли после обсуждений только дым в курилке B>или будет что-то конкретное в документе.
Будет что-то конкретное в коде — часто этого достаточно. Если принципиально то, что была выбрана именно кнопка, а не пункт меню и это знание хочется сохранить и использовать в дальнейшем — имеет смысл задокументировать это. Если нет — то найдутся и более достойные применения этому времени.
Здравствуйте, Кэр, Вы писали:
Кэр>Будет что-то конкретное в коде — часто этого достаточно. Если принципиально то, что была выбрана именно кнопка, а не пункт меню и это знание хочется сохранить и использовать в дальнейшем — имеет смысл задокументировать это. Если нет — то найдутся и более достойные применения этому времени.
А что жалеть время тех, у кого работа такая — анализ того,
что хочется клиенту и формализация этого дела в виде требований?
Мы ведь о промышленной разработке речь ведем
Здравствуйте, bkat, Вы писали:
Кэр>>Будет что-то конкретное в коде — часто этого достаточно. Если принципиально то, что была выбрана именно кнопка, а не пункт меню и это знание хочется сохранить и использовать в дальнейшем — имеет смысл задокументировать это. Если нет — то найдутся и более достойные применения этому времени.
B>А что жалеть время тех, у кого работа такая — анализ того, B>что хочется клиенту и формализация этого дела в виде требований? B>Мы ведь о промышленной разработке речь ведем
Так вы хотите чтобы аналитики анализ делали или формочку в деталях документировали? Или вы считаете, что затраты на анализ нулевые и чем бы они не занимались — пусть лучше хотя бы документы попишут? Зачем вам вообще этот документ нужен?
Его польза:
1. Хорошая база фиксирующая результата переговоров нескольких человек. Основная цель переговоров — создать код решающих конкретную задачу. Иногда целью также является следующий пункт.
2. Документ описывающий как система работает.
Больше я пользы от него не вижу. При этом у документа есть стоимость разработки и стоимость поддержки. Чем более детальный документ — тем выше стоимость изначальной разработки и уж тем более стоимость поддержки.
Принимая это во внимание ваше заявление "а документ все равно нужен" — возникает вопрос — любой ценой что ли? Тогда, пардон, это нифига не промышленная разработка. Потому что одна из основных целей этой разработки — получение прибыли из продукта.
Здравствуйте, Кэр, Вы писали:
Кэр>Так вы хотите чтобы аналитики анализ делали или формочку в деталях документировали? Или вы считаете, что затраты на анализ нулевые и чем бы они не занимались — пусть лучше хотя бы документы попишут? Зачем вам вообще этот документ нужен?
Ну утрировать можно что угодно...
А на шару хорошие спеки конечно не получить.
Кэр>Его польза: Кэр>1. Хорошая база фиксирующая результата переговоров нескольких человек. Основная цель переговоров — создать код решающих конкретную задачу. Иногда целью также является следующий пункт. Кэр>2. Документ описывающий как система работает.
Кэр>Больше я пользы от него не вижу.
А этого мало?
Фиксация результатов переговоров нескольких человек (туда кстати куча заинтересованных групп входит) — это весьма ценно.
Если девелоперы, тестеры и те, кто потом продукт будет продавать,
в целом одинаково понимают что делают — это очень сильно облегчает жизнь.
Но если система не очень объемная, команда небольшая, все друг друга знают
и ничего не забывают, то да, можно обойтись и без документированных спеков.
В коде и в самом деле потом почти все найдется, кроме того,
что забыли реализовать, потому что мелочь скучная
Вот представь себе писателей компилятора без формальной спецификации языка.
Что-то они конечно родят, но "по уму" было бы проще.
Здравствуйте, bkat, Вы писали:
B>А этого мало? B>Фиксация результатов переговоров нескольких человек (туда кстати куча заинтересованных групп входит) — это весьма ценно. B>Если девелоперы, тестеры и те, кто потом продукт будет продавать, B>в целом одинаково понимают что делают — это очень сильно облегчает жизнь. B>Но если система не очень объемная, команда небольшая, все друг друга знают B>и ничего не забывают, то да, можно обойтись и без документированных спеков. B>В коде и в самом деле потом почти все найдется, кроме того, B>что забыли реализовать, потому что мелочь скучная
Я работал в проекте где документировали практически все, вплоть до пикселей
И таких вещей как: договорились в курилке, по почте и т.д. старались не допускать.
Все это конечно муторно, но в итоге облегчает жизнь, в том числе и прикрывает пятую точку
На вопрос, а почему тут не так как мы хотели, всегда можно ткнуть носом в документик.
К тому же релизы шли в QA, а они ессно смотрят в требования\документацию.
Поэтому шанс получить баги очень высок, если сделано "как договорились в курилке" и
это никак не задокументировано. Ну объяснишь ты раз, что мол так и так, инвалид ваш баг,
в следующий раз будет уже кто-то другой тестировать, опять бага прилетит.
Но конечно да, проекты разные бывают. Есть такие где все вообще на словах.
