Комментарии 57
Не зря вы представляете недовольные лица людей - предварительная подготовка необходима и полезна, спору нет. Стандарты тоже замечательны, пока их не слишком много. И про выбор частей вы правильно думаете.
А вот использовать стандарты для описания того, кто чем занимается - это как? Я не понимаю. Лист требований - это тоже не стандарты. Использование системы контроля версий естественно разрешает проблему с кодом. Если вы не хотите разрешать конфликты версий - что ж, координируйте работу людей. Как это они у вас пишут один участок кода?
Определить, что вы хотите получить в итоге - это правильно. Но по списку требований вы не определите качества никогда. В проекте есть два качества - то, которое определяют программисты и то, которое определяет клиент. Если вы заставите программистов работать над продуктом, качество которого определяет клиент, они вряд ли будут довольны - качество клиента обычно ниже и из-за этого снижаются сроки. Из-за сниженных сроков программист вынужден писать менее качественный код, что противоречит его стандартам качества. Такой ситуации надо избегать - когда люди недовольны тем, что они делают, они делают это неохотно. Плюс, единственное. что будет волновать этих людей - когда же наконец выйдут из этого проекта.
Если у вас в середине проекта кто-то что-то говорит, значит:
Третий пункт наиболее важный - что-то случилось, из-за чего люди хотят избежать работы над проектом.
Вы же, вместо того, чтобы анализировать ситуацию и привести её в порядок, чтобы люди хотели работать над проектом, лишь добавляете бумажек, думая, что это спасёт ваш проект. А как у вас с текучестью кадров?
А вот использовать стандарты для описания того, кто чем занимается - это как? Я не понимаю. Лист требований - это тоже не стандарты. Использование системы контроля версий естественно разрешает проблему с кодом. Если вы не хотите разрешать конфликты версий - что ж, координируйте работу людей. Как это они у вас пишут один участок кода?
Определить, что вы хотите получить в итоге - это правильно. Но по списку требований вы не определите качества никогда. В проекте есть два качества - то, которое определяют программисты и то, которое определяет клиент. Если вы заставите программистов работать над продуктом, качество которого определяет клиент, они вряд ли будут довольны - качество клиента обычно ниже и из-за этого снижаются сроки. Из-за сниженных сроков программист вынужден писать менее качественный код, что противоречит его стандартам качества. Такой ситуации надо избегать - когда люди недовольны тем, что они делают, они делают это неохотно. Плюс, единственное. что будет волновать этих людей - когда же наконец выйдут из этого проекта.
Если у вас в середине проекта кто-то что-то говорит, значит:
- Вы не знаете навыков своих людей
- Вы не умеете ими управлять
- Люди не хотят делать этот проект
Третий пункт наиболее важный - что-то случилось, из-за чего люди хотят избежать работы над проектом.
Вы же, вместо того, чтобы анализировать ситуацию и привести её в порядок, чтобы люди хотели работать над проектом, лишь добавляете бумажек, думая, что это спасёт ваш проект. А как у вас с текучестью кадров?
простите, но вы написал полстраницы текста, не имеющего никакого отношения к исходному и очень полезному для начинающих посту.
НЛО прилетело и опубликовало эту надпись здесь
Да, конечно, для начинающих, которые хотят сразу встать на скользкую дорогу тотальных стандартизаций я написал пол страницы текста, не имеющего отношения…
Впрочем, это моё восприятие.
Впрочем, это моё восприятие.
О, поверьте - описанное в записи далеко не "тотальная стандартизация". Это минимально необходимые документы. Документы, без которых проекты проваливаются.
Я не хочу переходить на личности, но сюдя по профилю в МоемКруге - вы работаете уже три года в компании, в которой менее 10 человек. Соответственно - вы не занимались крупными (и даже средними) проектами. Для трех человек действительно можно обойтись без большинства документов. Особенно, если заказчик внутренний.
Если это хоть сколько-нибудь серьезный проект - пренебрежение четкими методиками управления проектом (пусть даже и agile) - преступление.
Я не хочу переходить на личности, но сюдя по профилю в МоемКруге - вы работаете уже три года в компании, в которой менее 10 человек. Соответственно - вы не занимались крупными (и даже средними) проектами. Для трех человек действительно можно обойтись без большинства документов. Особенно, если заказчик внутренний.
Если это хоть сколько-нибудь серьезный проект - пренебрежение четкими методиками управления проектом (пусть даже и agile) - преступление.
Ничего страшного, что вы посмотрели мой профиль в МоёмКруге, хоть какая-то от него польза ;) Восприятие средних и крупных проектов бывает разное, я затрудняюсь ответить. Документов у нас хватает, поверьте. Я уже горю желанием кое-что поменять в их системе. И я этого добьюсь ;)
Минимально необходимые документы - это план того, что нужно сделать. Называть его можно по-разному. Всё остальное тоже очень желательно, но план - нужен.
Чёткость должна быть, не спорю. Но представьте себе разработку по RUP? Это, знаете, такая беда больших компаний - излишняя формализация всего. Плюс, человек сам очень гибок, зачем его сковывать излишними методологиями?
Я понимаю, что не тотальная ;) Но долгий путь начинается с одного маленького шага. Воспроизвёл неточно, но суть осталась.
Минимально необходимые документы - это план того, что нужно сделать. Называть его можно по-разному. Всё остальное тоже очень желательно, но план - нужен.
Чёткость должна быть, не спорю. Но представьте себе разработку по RUP? Это, знаете, такая беда больших компаний - излишняя формализация всего. Плюс, человек сам очень гибок, зачем его сковывать излишними методологиями?
Я понимаю, что не тотальная ;) Но долгий путь начинается с одного маленького шага. Воспроизвёл неточно, но суть осталась.
Что значит "представьте себе разработку по RUP"? Я работал по RUP. И это было невероятно приятно. Впрочем, это было оправдано.
Понимаете, вам когда-нибудь приходилось создавать проекты, deployment которых не сводился просто к "svn up"?
Зачастую deployment превращается в довольно хитрую и сложную схему. Как обойтись без ее описания? Вот вам SCMP. SDD - просто описание архитектуры проекта. Как без нее?
Без SRS и вовсе не начинается ни один проект.
Понимаете, вам когда-нибудь приходилось создавать проекты, deployment которых не сводился просто к "svn up"?
Зачастую deployment превращается в довольно хитрую и сложную схему. Как обойтись без ее описания? Вот вам SCMP. SDD - просто описание архитектуры проекта. Как без нее?
Без SRS и вовсе не начинается ни один проект.
О, я имел в виду то, что это достаточно формализованный процесс. Но раз вам нравилось… Думаю, это проблема мировоззрения - мне претит излишняя бюрократия и формализм.
Насчёт развёртывания, так его уже давно можно говорить по-русски, все поймут. Деплоймент же меня смущает, знаете, как в книге, где переводчик затруднился перевести термин.
Ну, и если надо где-то развёртывать проект, то естественно изучить, что есть и что надо, поэтому план развёртывания нужен. Но воротить большой док с описанием всех процессов? Для этого надо иметь огромную команду с очень плохой координацией, либо очень плохие условия.
Я ещё раз повторюсь насчёт того, что определить, что необходимо получить в итоге - правильно и просто обязательно. Сюда, вполне естественно, входят требования к продукту и его архитектура.
Но описывать кто в команде чем занимается - это уже слишком. Это не команда, если её член не знает чем он занимается. Если же люди не знают, что делать и куда приложить силы, это проблема координации. И уж тем более, есть какая-то проблема, если кто-то в середине проекта вдруг стал недоволен.
Таким образом - предварительному планированию, сбору требований и созданию архитектуры - да. Описанию процедуры развёртывания, особенное если оно сложное - естественно да. А остальному - нет. Никаких описаний кто в команде чем занимается. Никаких попыток описать все процессы, выполняемые человеком и свести их в документ. Описать все процессы невозможно, а человек - не робот.
Ни один проект не начнётся без людей ;)
Насчёт развёртывания, так его уже давно можно говорить по-русски, все поймут. Деплоймент же меня смущает, знаете, как в книге, где переводчик затруднился перевести термин.
Ну, и если надо где-то развёртывать проект, то естественно изучить, что есть и что надо, поэтому план развёртывания нужен. Но воротить большой док с описанием всех процессов? Для этого надо иметь огромную команду с очень плохой координацией, либо очень плохие условия.
Я ещё раз повторюсь насчёт того, что определить, что необходимо получить в итоге - правильно и просто обязательно. Сюда, вполне естественно, входят требования к продукту и его архитектура.
Но описывать кто в команде чем занимается - это уже слишком. Это не команда, если её член не знает чем он занимается. Если же люди не знают, что делать и куда приложить силы, это проблема координации. И уж тем более, есть какая-то проблема, если кто-то в середине проекта вдруг стал недоволен.
Таким образом - предварительному планированию, сбору требований и созданию архитектуры - да. Описанию процедуры развёртывания, особенное если оно сложное - естественно да. А остальному - нет. Никаких описаний кто в команде чем занимается. Никаких попыток описать все процессы, выполняемые человеком и свести их в документ. Описать все процессы невозможно, а человек - не робот.
Ни один проект не начнётся без людей ;)
Простите, опять же, но у меня такое ощущение, что у вас в голове какая-то каша из нахватанных откуда-то умных терминов, сложноподчиненных предложений и полное отсутствие практики.
Насчёт каши. Она там бывает, что, впрочем, не является моей привилегией.
Насчёт терминов. Посмотрите, я перегрузил ими текст? Нет? Ах, боже мой.
Предложения мои - это дело моего подхода. Лучше конечно выражаться односложно, это упрощает взаимодействие.
Практика… Научите меня вычислять её количество по написанному тексту, я вам буду благодарен.
Я вас прощаю.
Насчёт терминов. Посмотрите, я перегрузил ими текст? Нет? Ах, боже мой.
Предложения мои - это дело моего подхода. Лучше конечно выражаться односложно, это упрощает взаимодействие.
Практика… Научите меня вычислять её количество по написанному тексту, я вам буду благодарен.
Я вас прощаю.
Описывать, кто чем в проекте занимается, необходимо как минимум тогда, когда в проекте есть представители Заказчика и Исполнителя. У тех и у других есть свои обязанности, и формализация этих обязанностей - безусловное благо для проекта.
НЛО прилетело и опубликовало эту надпись здесь
1. Я говорил о контексте «В-третьих, для того чтобы не произошла ситуация, что оба программиста одновремено разрабатывают класс…»
2. Это естественно. Но всё же я считаю, что клиент не должен иметь решающего слова в определении качества, потому что, как я уже писал, разработчики неохотно работают над тем, что не удовлетворяет их стандартам качества.
3. Если команде нужны стандарты для описания зон ответственности и правила взаимодействия, то скорее всего это не команда.
4. Команда разработчиков - это команда разработчиков. Если вы приглядитесь, то увидите, что менеджеры всё-таки находятся в стороне, если, конечно, не принимают активное участие в проекте. А остальные товарищи представляют собой отдельные команды со своими проблемами.
2. Это естественно. Но всё же я считаю, что клиент не должен иметь решающего слова в определении качества, потому что, как я уже писал, разработчики неохотно работают над тем, что не удовлетворяет их стандартам качества.
3. Если команде нужны стандарты для описания зон ответственности и правила взаимодействия, то скорее всего это не команда.
4. Команда разработчиков - это команда разработчиков. Если вы приглядитесь, то увидите, что менеджеры всё-таки находятся в стороне, если, конечно, не принимают активное участие в проекте. А остальные товарищи представляют собой отдельные команды со своими проблемами.
претензии по мелочи - к примеру, программисты не определяют качество продукта.
А как же качество кода?
качество кода тоже не определяет качество продукта. Есть гораздо более важные вещи.
Программист - быть может, художник. Программисту нужно знать что то, что он пишет правильно и разумно. Ему нужно знать, что он использует cutting edge техники и что от него что-то зависит.
Продукту этого не нужно. Продукту нужен успех.
А если вернуться к исходной записи - там речь шла и вовсе совершенно об ином. О совершенно необходимых вещах, чуть только ваш проект стал чуть взрослее детского сада. Если над ним работают хотя бы 20 человек.
Программист - быть может, художник. Программисту нужно знать что то, что он пишет правильно и разумно. Ему нужно знать, что он использует cutting edge техники и что от него что-то зависит.
Продукту этого не нужно. Продукту нужен успех.
А если вернуться к исходной записи - там речь шла и вовсе совершенно об ином. О совершенно необходимых вещах, чуть только ваш проект стал чуть взрослее детского сада. Если над ним работают хотя бы 20 человек.
Напишите про гораздо более важные вещи, я почитаю.
Качество кода, естественно не определяет качество продукта полностью, но частично - точно.
Успех нужен не продукту, это вы привираете ;) Успех нужен верхнему эшелону руководства.
А если вернуться к исходной записи, то координация - необходимая вещь, даже если ты работаешь один. Естественно, что при большой команде координироваться надо лучше. Но для этого вовсе не обязательно переводить килограммы бумаги.
Качество кода, естественно не определяет качество продукта полностью, но частично - точно.
Успех нужен не продукту, это вы привираете ;) Успех нужен верхнему эшелону руководства.
А если вернуться к исходной записи, то координация - необходимая вещь, даже если ты работаешь один. Естественно, что при большой команде координироваться надо лучше. Но для этого вовсе не обязательно переводить килограммы бумаги.
Качество кода важно, но меньше - чем качество взаимодействия, качество интерфейса. И вообще качество соответствия ожидания людей от продукта с самим продуктом.
Об этих вещах можно почитать, например, у Алана Купера: "Психбольница в руках пациентов" (fictionbook-html, купить на Ozon'е
Об этих вещах можно почитать, например, у Алана Купера: "Психбольница в руках пациентов" (fictionbook-html, купить на Ozon'е
И вы на протяжении нескольких лет работаете над проектами, успех которых нужен только верхнему эшелону - я вам очень сочувствую. Правда.
Есть некоторые претензии к основному тексту, но свою цель он достиг - заставил усомниться в том, что проект можно взять блицкригом с налета и без подготовки.
Последнее время очень часто, к сожалению, говорю фразу:
"Нечего пинать на реализацию, если архитектуру просрали"
Так что уделяйте больше времени на проектирования проекта - это время никогда не будет потрачено зря...
"Нечего пинать на реализацию, если архитектуру просрали"
Так что уделяйте больше времени на проектирования проекта - это время никогда не будет потрачено зря...
Про методологии разработки программного обеспечения написано достаточно. И спору нет их надо знать. Но не всегда все так как пишет автор статьи. Не всегда известны функциональные требования к системе на 100% в начале проекта.
Не всегда плохо переписать ядро 15 раз. И даже лучше писать ПО чтобы можно было его переписывать. И желательно частями, а не целиком сразу - когда архитектура изначально четко заложена.
Когда разрабатываешь ядерную боеголовку и ПО для нее - тогда нужно 100% следование стандартам и обширная предпроектная подготовка.
Если же ПО само по себе динамическое, и может меняется со временем в зависимости от растущих потребностей пользователей - тогда и подходы должны быть более гибкими. Но в целом я с автором согласен - проектировать надо, но может не всегда по схеме им предложенной. Гибкость подхода нужно применять товарищи!
Не всегда плохо переписать ядро 15 раз. И даже лучше писать ПО чтобы можно было его переписывать. И желательно частями, а не целиком сразу - когда архитектура изначально четко заложена.
Когда разрабатываешь ядерную боеголовку и ПО для нее - тогда нужно 100% следование стандартам и обширная предпроектная подготовка.
Если же ПО само по себе динамическое, и может меняется со временем в зависимости от растущих потребностей пользователей - тогда и подходы должны быть более гибкими. Но в целом я с автором согласен - проектировать надо, но может не всегда по схеме им предложенной. Гибкость подхода нужно применять товарищи!
В случае если Вам незнакомы функциональные требования к системе на 100% в начале проекта порой рекомендую использовать метод набегающей волны - т.е. уточнение требований по мере проектирования системы. Весьма полезный метод ИМХО
Да я и не настаиваю именно на этой схеме :) Моя цель была подтолкнуть людей к *элементарной* документации и проектированию, а если они не знают как и что - прочитать стандарты, а потом подогнать их под себя.
Я бы сказал - людей лучше подталкивать к изучению методологий разработки и их применению. А то что Вы предлагаете - это выдранные из контекста практики. И почему-то Вы выбрали только один из возможных вариантов их использования. Никто не говорит что не надо проектировать, планировать, и тестировать.
Например само по себе тестирование - очень полезная вещь и тестировать можно без предварительного проектирования по стандартам как вы описывали.
Надо Вам написать функцию сложения двух чисел? Сначала пишешь тест, в котором проверяется работы этой функции. По сути просто вызываем функцию с двумя параметрами и сравниваем с верным показателем. Тоько после этого пишем код самой функции. Чем не тестирование перед проектированием - даже круче - перед кодированием.
Почему проектировать систему сразу не по ходу реализации ее функций. Зачем писать документацию на систему - если она нужна только ее разработчикам. А разработчик и так ее знают как свои пять пальцев - потому что сами же и написали. Вот другая точка зрения.
Есть разные методологии. И я не говорю о том что проектировать не нужно - просто это можно делать по разному, как это делать определятся в каждом конкретном случае.
Например само по себе тестирование - очень полезная вещь и тестировать можно без предварительного проектирования по стандартам как вы описывали.
Надо Вам написать функцию сложения двух чисел? Сначала пишешь тест, в котором проверяется работы этой функции. По сути просто вызываем функцию с двумя параметрами и сравниваем с верным показателем. Тоько после этого пишем код самой функции. Чем не тестирование перед проектированием - даже круче - перед кодированием.
Почему проектировать систему сразу не по ходу реализации ее функций. Зачем писать документацию на систему - если она нужна только ее разработчикам. А разработчик и так ее знают как свои пять пальцев - потому что сами же и написали. Вот другая точка зрения.
Есть разные методологии. И я не говорю о том что проектировать не нужно - просто это можно делать по разному, как это делать определятся в каждом конкретном случае.
А завтра вы возьмете в команду нового разработчика, потому как старые перестанут справляться физически или уйдет кто-то.. и этот новенький просто потонет под грузом чужого кода, который писался "как удобнее" и не документирован вообще никак. Хорошо, если будет кто-то, кто проектировал систему и досконально знает структуру и при этом способен грамотно объяснить что к чему, а если нет?
Варианта два: либо подскажут "старики",
либо программист разберется в коде сам - ели он конечно профессионал.
Если не профессионал, и некому объяснить - гиблое дело, такому никакая документация не поможет. Программист должен уметь читать код, как чужой так и свой. И кроме того грамотно его писать. Если функция размером в 40 экранов - тут какую хочешь документацию пиши - все одно - хрен разберешь.
И кстати, OpenSource проекты, часто там документация? Максимум на API - и то когда это библиотека :-) Народу же с этим кодом работает гораздо больше, чем с напрочь задокументированными системами. И ничего - не жужжат! :-)
либо программист разберется в коде сам - ели он конечно профессионал.
Если не профессионал, и некому объяснить - гиблое дело, такому никакая документация не поможет. Программист должен уметь читать код, как чужой так и свой. И кроме того грамотно его писать. Если функция размером в 40 экранов - тут какую хочешь документацию пиши - все одно - хрен разберешь.
И кстати, OpenSource проекты, часто там документация? Максимум на API - и то когда это библиотека :-) Народу же с этим кодом работает гораздо больше, чем с напрочь задокументированными системами. И ничего - не жужжат! :-)
>Что же сделать что-бы этого избежать и при этом не заниматься планированием по пол-года?
Набираться опыта.
Набираться опыта.
Хотелось бы, что бы люди имеющие реальный опыт работы выложили посмотреть ещё несколько примеров того, как они ведут документацию. Понимаю, что это далеко не всегда возможно, но вдруг )
Желательно на русском )
Желательно на русском )
Статья правильная, а вот про документацию есть вопросы.
С одной стороны, я рад, что наконец-то увидел систематическое описание требований к игре, давно хотелось понять, как к этому подходят в игровом мире.
С другой стороны, удивило, что документы "концепт-документ" и "спецификация требований" в основном описывают не требования к ПО как таковые, сколько то, что классически принято называть "бизнес-модель" (модель предметной области, domain model) - а именно - понятия создаваемого игрового мира, их свойства, взаимосвязи, правила взаимодействия и эволюции.
Т.е. в приведённых документах описано не проектирование ПО, а проектирование игры. Причём параллелей между классическим SRS и приведённой "спецификацией требований" я вообще не увидел, кроме разве того, что оба представляют собой структурированные документы.
Возможно, для геймдизайна подобный акцент на описания моделируемого мира и правилен, но в начале статьи речь шла о стартапах и веб-разработке вообще, и для них всё-таки в большинстве своём Vision и SRS должны говорить в терминах ключевых функций, информационной архитектуры, видов страниц, состава страниц, видов сервисов, сценариев использования, макетов страниц, нефункциональных требований и т.д., что впрочем и упомянуто в самой статье.
С одной стороны, я рад, что наконец-то увидел систематическое описание требований к игре, давно хотелось понять, как к этому подходят в игровом мире.
С другой стороны, удивило, что документы "концепт-документ" и "спецификация требований" в основном описывают не требования к ПО как таковые, сколько то, что классически принято называть "бизнес-модель" (модель предметной области, domain model) - а именно - понятия создаваемого игрового мира, их свойства, взаимосвязи, правила взаимодействия и эволюции.
Т.е. в приведённых документах описано не проектирование ПО, а проектирование игры. Причём параллелей между классическим SRS и приведённой "спецификацией требований" я вообще не увидел, кроме разве того, что оба представляют собой структурированные документы.
Возможно, для геймдизайна подобный акцент на описания моделируемого мира и правилен, но в начале статьи речь шла о стартапах и веб-разработке вообще, и для них всё-таки в большинстве своём Vision и SRS должны говорить в терминах ключевых функций, информационной архитектуры, видов страниц, состава страниц, видов сервисов, сценариев использования, макетов страниц, нефункциональных требований и т.д., что впрочем и упомянуто в самой статье.
Сейчас эпоха сервисов и прелесть в том, что вместо того чтобы потратить, например неделю на планирование и проработку будущего стартапа - можно за то же время сделать работающий прототип на базе различных сервисов и frameworkов, выставить его на публику и посмотреть на реакцию. И дальше, если "зажгло" - приступить к планированию, реализации и т.п., причем с учетом полученного фидбэка.
Я пишу это потому что много времени работал в крупных компаниях и разрабатывал и внедрял ПО по различным методологиям. Когда делал свой первый стартап - потратил на него полгода - и в итоге -пшик, не выстрелил. Сейчас я вижу что можно было понять что проект "не пойдет" сделав за пару недель простенький прототип. Безумно жаль потраченного времени. Поэтому истина как всегда где то посередине. Не стОит делать упор на планировании и проработке по крайней мере до тех пор пока не станет ясно что проект потенциально удачен.
Я пишу это потому что много времени работал в крупных компаниях и разрабатывал и внедрял ПО по различным методологиям. Когда делал свой первый стартап - потратил на него полгода - и в итоге -пшик, не выстрелил. Сейчас я вижу что можно было понять что проект "не пойдет" сделав за пару недель простенький прототип. Безумно жаль потраченного времени. Поэтому истина как всегда где то посередине. Не стОит делать упор на планировании и проработке по крайней мере до тех пор пока не станет ясно что проект потенциально удачен.
Не думаю, что день-два сыграет большую роль, ведь именно столько понадобится для "простенького" прототипа. Кстати прошу заметить, я делаю акцент именно на минимум документации. Я тоже против кучи бумаг, но считаю что основы должны быть расписаны.
В таком случае не совсем понимаю смысл планирования на начальном этапе.
Ну хорошо, давайте на конкретном примере.
Допусти есть идея сделать стартап отвечающий на вопрос:
"Что подарить?" (родилась 5 минут назад, после звонка жены:) )
Итак, опишем функциональные требования:
Цель: Ответ на вопрос что подарить определенной категории людей на определенное событие
Функционал:
Пользователь регистрируется, заполняет профиль и описывает самый идиотский и самый понравившийся подарок в своей жизни.
С обязательным указанием на какое событие (ДР, свадьба и т.п.) и комментариями почему. Возможность комментировать
В профиле минимум - пол, возраст, примерный доход
Почему будут писать: - похвастаться
Как будут искать: по типу события и профилю - возраст доход и т.п.
Монетизация: реклама ларьков с сувенирами.
Вот собственно план. Дальше берем первую попавшуюся цмс или фреймворк, делаем сайт - и показываем его как можно большему кол-ву людей. Смотрим на фидбэк, что не удобно, чего добавить, что исправить и если людям интересно - заказываем/покупаем дизайн, нанимаем/берем в долю программиста программиста и делаем на чистовик. Выпуск - доработка по фидбэку - маркетинг - продажа - следующий стартап.
Т.е. вся прелесть - делаем все быстро. Не заморачиваясь на:
Software project management plan, Software Requirements Specification и т.п.
Надо опираться на отзывы реальных пользователей а не додумывать за них. А не выстрелит - забросить на раннем этапе и заняться другим чем-ть.
В общем Ваша статья больше подходит к разработке каких нибудь ЕРП систем, чем к запуску стартапа. Ну или к сложным стартапам с большой командой.
Ну хорошо, давайте на конкретном примере.
Допусти есть идея сделать стартап отвечающий на вопрос:
"Что подарить?" (родилась 5 минут назад, после звонка жены:) )
Итак, опишем функциональные требования:
Цель: Ответ на вопрос что подарить определенной категории людей на определенное событие
Функционал:
Пользователь регистрируется, заполняет профиль и описывает самый идиотский и самый понравившийся подарок в своей жизни.
С обязательным указанием на какое событие (ДР, свадьба и т.п.) и комментариями почему. Возможность комментировать
В профиле минимум - пол, возраст, примерный доход
Почему будут писать: - похвастаться
Как будут искать: по типу события и профилю - возраст доход и т.п.
Монетизация: реклама ларьков с сувенирами.
Вот собственно план. Дальше берем первую попавшуюся цмс или фреймворк, делаем сайт - и показываем его как можно большему кол-ву людей. Смотрим на фидбэк, что не удобно, чего добавить, что исправить и если людям интересно - заказываем/покупаем дизайн, нанимаем/берем в долю программиста программиста и делаем на чистовик. Выпуск - доработка по фидбэку - маркетинг - продажа - следующий стартап.
Т.е. вся прелесть - делаем все быстро. Не заморачиваясь на:
Software project management plan, Software Requirements Specification и т.п.
Надо опираться на отзывы реальных пользователей а не додумывать за них. А не выстрелит - забросить на раннем этапе и заняться другим чем-ть.
В общем Ваша статья больше подходит к разработке каких нибудь ЕРП систем, чем к запуску стартапа. Ну или к сложным стартапам с большой командой.
Описать стартап в таком виде как сделали Вы - лучше, чем вообще ничего не написать. Была хорошая фраза, к сожалению не помню дословно, но смысл: Пока идея не записана, она не существует. Опишите проект хоть как-то, если будете использовать какую-нибудь методику или стандарт, то шанс того что вы ничего не забудете в процессе намного выше.
PS: Ещё один момент - преимущество стартапов перед крупными корпорациями - их мобильность. За то время как корпорация потратит полгода на фазу планирования - стартап успеет "выстрелить" и отъесть часть рынка. Если он будет повторять путь корпорации то проиграет ещё на фазе планирования, так как бюджет кончится)
Всё верно, согласен на все 100%. Этап планирования в стартапе нужно сократить, но не убрать.
Кончено нельзя - а то целей для разработчиков не будет. Только планировать надо как можно чаще - иначе план свою актуальность потеряет. И сам процесс должен занимать как можно меньше времени. В плане должно быть написано столько - сколько нужно программисту для понимания и не строчкой больше. А как реализовать мы сами знаем :-)
Ох, вот поэтому мы и имеем триста клонов одного и того же, работающих кое-как.. :(
Проектирование пользовательского интерфейса может занят 15% - 20% времени и ресурсов при разработке информационных систем. Тщательная проработки интерфейса действительно поможет избежать разного рода ошибок на ранних этапах разработки. Но для этого лучше всего не привлекать программистов у них совершенно иное мышление нежели требуется на проектирование интерфейсов.
А может занять и 50 и 100% времени - и потом получится что те мелочи которы проработали сразу - совсем не такие - потому как технически сложно реализовать, и видение у заказчика поменялось, и вообще мир не стоит на месте :-) Как-то не экономно получается... Не аккуратненько :-)
А для этого есть авторский надзор, как у архитекторов:
http://www.google.ru/search?q=%D0%B0%D0%…
http://www.google.ru/search?q=%D0%B0%D0%…
А оно надо? Вот к примеру проект рассчитанный на два года реализации. Первый этап - через два месяца создать версию с минимальным функционалом и запустить в эксплуатацию. Далее еще через два месяц надо вторую версию с расширенным функционалом. Еще через два с нагрузкой на 10000 одновременных активных пользователей и так далее.
Что мы делаем в соответствии с описанной методой:
- мы проектируем систему с учетом всех возможных расширений - два месяца
- разрабатываем ядро системы с учетом возможностей его расширения и повышения производительности за счет масштабирования аппаратных средств - два месяца минимум, а то и пол года (какую спецификацию написать :-) )
- разрабатываем минимальный функционал, закупаем оборудование, устанавливаем - два месяца (опять таки минимум)
Получилось странное! Прошло пол года - а у нас классная штука с ядром и чем-то по спецификации. Заказчик уже 4 месяца ждет первой версии чтобы ее раскручивать по всякому. А у нас понимаешь ли спецификации и жесткая архитектура.
Не всегда методика описанная автором статьи соответствует реальности. Не спорю - проектировать и планировать надо. Но не обязательно так и в такой последовательности. Вариантов много и для каждого проекта нужно подбирать наиболее подходящий.
Что мы делаем в соответствии с описанной методой:
- мы проектируем систему с учетом всех возможных расширений - два месяца
- разрабатываем ядро системы с учетом возможностей его расширения и повышения производительности за счет масштабирования аппаратных средств - два месяца минимум, а то и пол года (какую спецификацию написать :-) )
- разрабатываем минимальный функционал, закупаем оборудование, устанавливаем - два месяца (опять таки минимум)
Получилось странное! Прошло пол года - а у нас классная штука с ядром и чем-то по спецификации. Заказчик уже 4 месяца ждет первой версии чтобы ее раскручивать по всякому. А у нас понимаешь ли спецификации и жесткая архитектура.
Не всегда методика описанная автором статьи соответствует реальности. Не спорю - проектировать и планировать надо. Но не обязательно так и в такой последовательности. Вариантов много и для каждого проекта нужно подбирать наиболее подходящий.
Есть ТЗ, есть системные архитекторы, в конце концов. Да и мелочи как правило прорабатывают с умом и в свое время.
Редко я встречал проекты, в которых конечный продукт соответствовал ТЗ на 100%. Если, конечно ТЗ писал не сам исполнитель, и в таком виде, что ему может соответствовать, что угодно, за ради прикрытия задницы :-)
Системный архитекторы - вообще забавные люди - бывают двух типов:
1) Теоретик - пишет что и как писать и никто так не делает; Часто встречается в ИТ отделах не ИТ компания (заводов например)
2) Царь и бог - что-то придумал, что-то написал. Все остальные пишут UI и вспомогательные функции как могут, а точнее как получится. Потому как "богу" не до UI и мелочи всякой! Получается дикий, необузданный монстр с афигенной архитектурой - этакий цифровой Франкенштейн! :-)
Системный архитекторы - вообще забавные люди - бывают двух типов:
1) Теоретик - пишет что и как писать и никто так не делает; Часто встречается в ИТ отделах не ИТ компания (заводов например)
2) Царь и бог - что-то придумал, что-то написал. Все остальные пишут UI и вспомогательные функции как могут, а точнее как получится. Потому как "богу" не до UI и мелочи всякой! Получается дикий, необузданный монстр с афигенной архитектурой - этакий цифровой Франкенштейн! :-)
Конечно, все хотят кушать, и проектировщики интерфейсов тоже. Но Купер немного передёргивает, впрочем, как и многие товарищи с похожими мыслями. Впрочем, понять их можно - голод штука такая ;)
Не знаю, как там отбирают на проектирование интерфейсов по мышлению, но поверьте, достаточно поработать вместе с пользователями вашего продукта в реальных условиях и вы обретёте просветление. Тогда интерфейс очень быстро разгрузится от лишнего. Такое сейчас происходит в проекте, который я внедряю. Главное - узнать, что пользователю необходимо, какая информация. И какая будет полезна. Но это мой опыт, для других он может разниться.
Не знаю, как там отбирают на проектирование интерфейсов по мышлению, но поверьте, достаточно поработать вместе с пользователями вашего продукта в реальных условиях и вы обретёте просветление. Тогда интерфейс очень быстро разгрузится от лишнего. Такое сейчас происходит в проекте, который я внедряю. Главное - узнать, что пользователю необходимо, какая информация. И какая будет полезна. Но это мой опыт, для других он может разниться.
Есть превосходные "легкие" методологии создания программного продукта. Они расчитаны на малые группы разработчков до 10 человек.
Формулировка требований - Use Case, см. книгу Алистера Коуберна.
Легкие методологии - Clear Case того же автора, Extreme Programming by Kent Beck.
Лично я сторонник экстремального программирования и его практик.
Формулировка требований - Use Case, см. книгу Алистера Коуберна.
Легкие методологии - Clear Case того же автора, Extreme Programming by Kent Beck.
Лично я сторонник экстремального программирования и его практик.
Он кОбёрн, безо всяких ОУ: http://alistair.cockburn.us/index.php/Ma…
Если мне память не изменяет, методология называется Crystal Clear. Clear Case - это система контроля кода компании Rational.
А в целом - гибкие методологии позволяют получить продукт на порядок быстрей и качественнее, чем следуя тяжеловесным методология аля RUP. Документация, как и любой артефакт, требует времени на поддержание и модификацию, причем чем ее больше тем ситуация хуже. Все указанные в статье документы помогают проекту достигнуть запланированного результата, но не гарантируют успеха проекта в целом. Так что выпуск проекта за 3 месяца по быстрым методологиям в большинстве случаев гораздо лучше, чем когда релиз происходит в том же объеме, но через год, зато следуя "тяжелым" методологиям. У Коберна есть чудная книга "Быстрая разработка", где подробно объясняется с чем это связано
А в целом - гибкие методологии позволяют получить продукт на порядок быстрей и качественнее, чем следуя тяжеловесным методология аля RUP. Документация, как и любой артефакт, требует времени на поддержание и модификацию, причем чем ее больше тем ситуация хуже. Все указанные в статье документы помогают проекту достигнуть запланированного результата, но не гарантируют успеха проекта в целом. Так что выпуск проекта за 3 месяца по быстрым методологиям в большинстве случаев гораздо лучше, чем когда релиз происходит в том же объеме, но через год, зато следуя "тяжелым" методологиям. У Коберна есть чудная книга "Быстрая разработка", где подробно объясняется с чем это связано
Самое важное в этом посте - то что проектирование должно иметь место. А то часто, когда начинаешь веб20 проджект в голову бьёт стартапная романтика.
По моему опыту стандартизированные подходы слабо походят для команды 2-3 человека которая делает продукт для енд-пользователей а не клиента.
Я подчеркнул из "Getting Real" и проверил и практике, что самым лучшим "проектированием" для веб приложений является дизайн всех интерфейсов. Только на основе всех готовых шаблонов можно писать код.
А по поводу управления проектами есть прекрасная книжка Deadline. Роман об управлении проектами (Том ДеМарко)
По моему опыту стандартизированные подходы слабо походят для команды 2-3 человека которая делает продукт для енд-пользователей а не клиента.
Я подчеркнул из "Getting Real" и проверил и практике, что самым лучшим "проектированием" для веб приложений является дизайн всех интерфейсов. Только на основе всех готовых шаблонов можно писать код.
А по поводу управления проектами есть прекрасная книжка Deadline. Роман об управлении проектами (Том ДеМарко)
По сути, делаешь интерфейс и его реализуешь (поддерживаю citycat). Принцип DRY это весчь. Нормальный проектировщик всё в мозгу без проблем должен удержать.
Ну и промолчу о том, что природа 2.0 заставляет постоянно модернизировать приложение... Короче бессмысленно писать все эти бумажки, диаграммки.
Ну и промолчу о том, что природа 2.0 заставляет постоянно модернизировать приложение... Короче бессмысленно писать все эти бумажки, диаграммки.
Господа, все смешали в кучу проект, продукт, стартап, web 2.0... А, между тем, на мой взгляд, основная мысль автора (которую я поддерживаю): следование _стандартам_ может сэкономить вам выходные ;).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Забытая фаза проектирования