Comments 52
Занимаюсь чем-то схожим, но автоматизирую технологические процессы.
Если не секрет, сколько человекочасов заняло создание такого программного продукта? А какая платформа использовалась? (C++/C#/Java/Oracle/Web server+язык/?).
Пол года. Три месяца до рабочего макета. Ещё два месяца до финальной версии и месяц — на доводку. Писалось в свободное время.
Использовался Delphi. Ибо позволяет достичь максимального результата за минимальные сроки при минимальном уродовании. В будущем буду использоваться Java. C++ — слишком трудоёмко, негибко и не удобно для визуализации. .Net на тот момент была тёмной лошадкой со странными перспективами.
Использовался Delphi. Ибо позволяет достичь максимального результата за минимальные сроки при минимальном уродовании. В будущем буду использоваться Java. C++ — слишком трудоёмко, негибко и не удобно для визуализации. .Net на тот момент была тёмной лошадкой со странными перспективами.
Ах да, интересное замечание — в качестве сервера баз данный был выбран Interbase (firefox). Т.к. по личным наблюдения только он может пять лет работать без обслуживания на офисном компьютере, который даже выключают иногда прямо пилотом, и не нарушить целостность базы. Всё остальное или стоило много денег, или (как например MySQL и иже с ним) не обеспечивало надёжности и отказоустойчивости.
Как оценивали стоимость проекта? Просто торговались исходя из цены на рынке или как то измеряли и обосновывали?
Ваш рассказ — хороший пример того, как помогает проекту грамотный системный и бизнес-анализ.
Ваш рассказ — хороший пример того, как помогает проекту грамотный системный и бизнес-анализ.
Ну, прежде всего это был далеко не первый мой подобный проект и цены я приблизительно знал. Но конкретно тот проект оценивал сугубо из здравого смысла — желаемая зарплата помноженная на время работы. В некотором роде продешевил, но, во-первых, заказчик остался счастлив, а, во-вторых, реальная трудоёмкость и загрузка были далеко не 100% — после установки пробной версии работать приходилось лишь время от времени :)
Вы описали случай разработки системы одним человеком. А может у Вас есть опыт командной разработки?
В первую очередь интересует вопрос распределения обязанностей между членами команды: должен ли общаться с заказчиком только один человек (а-ля team manager) или каждый разрабочик должен общаться по вопросам области его ответственности?
В первую очередь интересует вопрос распределения обязанностей между членами команды: должен ли общаться с заказчиком только один человек (а-ля team manager) или каждый разрабочик должен общаться по вопросам области его ответственности?
Такой опыт тоже есть. Хотя и меньший. Как негативный так и позитивный.
Главное — чёткое разделение ролей и субординация.
С заказчиком должен общаться один человек. Если есть необходимость чтобы общались несколько, то должно быть чёткое разграничение области компетенции. В любом случае любые обещания должен давать и согласовывать один человек — нарушение этого правила погубило несколько проектов.
Обязательно должен быть человек с правом решающего голоса. Так как иногда на ровном месте возникают споры по пустяку — должен быть однозначный способ разрешения таких ситуаций.
Возможно, когда-нибудь, изложу негативный и очень поучительный опыт работы в команде :)
Главное — чёткое разделение ролей и субординация.
С заказчиком должен общаться один человек. Если есть необходимость чтобы общались несколько, то должно быть чёткое разграничение области компетенции. В любом случае любые обещания должен давать и согласовывать один человек — нарушение этого правила погубило несколько проектов.
Обязательно должен быть человек с правом решающего голоса. Так как иногда на ровном месте возникают споры по пустяку — должен быть однозначный способ разрешения таких ситуаций.
Возможно, когда-нибудь, изложу негативный и очень поучительный опыт работы в команде :)
Как видно из статьи, автор уделяет большое внимание управлению требованиями. Это очень грамотная позиция.
По моему мнению, правильное управление требованиями — один из ключевых факторов успеха проекта и снижения рисков при разработке.
По моему мнению, правильное управление требованиями — один из ключевых факторов успеха проекта и снижения рисков при разработке.
Классный текст, подпишусь почти под каждым словом.
Особенно верно на счет длинных мануалов, которые обычно требуют писать «шоб было». Самый верный мануал — это лист A4 (бумажный!) с Quick Start гайдом, в котором написано как запустить, залогиниться, создать что\то (документ\запись\счет), сохранить, открыть, отредактировать. Всё! Больше листа А4 читать никто не будет.
Еще — обязательно хот-кеи! Вам кажется что у Вас в ПО классные и логичные кнопки, есть контекстные менюшки и в главном меню хорошая структура? Люди будут работать в этом годами! Каждое действие, на которое нет хоткея — это минус 1-2 секунды. На 1000 раз в день. На годы работы. Понимаете, сколько Вы людям сэкономите времени жизни? Система хот-кеев, к стати, должна быть настраиваемой. Вы понятия не имеете, как юзеру удобно.
Особенно верно на счет длинных мануалов, которые обычно требуют писать «шоб было». Самый верный мануал — это лист A4 (бумажный!) с Quick Start гайдом, в котором написано как запустить, залогиниться, создать что\то (документ\запись\счет), сохранить, открыть, отредактировать. Всё! Больше листа А4 читать никто не будет.
Еще — обязательно хот-кеи! Вам кажется что у Вас в ПО классные и логичные кнопки, есть контекстные менюшки и в главном меню хорошая структура? Люди будут работать в этом годами! Каждое действие, на которое нет хоткея — это минус 1-2 секунды. На 1000 раз в день. На годы работы. Понимаете, сколько Вы людям сэкономите времени жизни? Система хот-кеев, к стати, должна быть настраиваемой. Вы понятия не имеете, как юзеру удобно.
Очень хорошо, но, к сожалению, мало применимо к удалённой работе.
UFO just landed and posted this here
Сдаётся, слышу я ехидство в Вашем тоне… 11 лет и несколько десятков проектов пойдёт? Кому интересно — без проблем найдут мое резюме. И я категорически отказываюсь флудить по этому поводу.
В посте описан по сути очередной «Опердень» как класс задач. Кстати, интересно, что продукт покрывал автоматизацией? какую область деятельности?
Судя по тексту, описана итерационная разработка продукта по сути с нечеткими начальными требованиями. «Набросал каркас», «Не понравится — переделаю все бесплатно». В реальной жизни вообще такое очень редко бывает.
Вторая особенность, которая сквозит — это то, что речь о заказной разработке для одного конкретного заказчика. Без какого-либо обобщения такой подход по опыту не тиражируем на других заказчиков, где отчет будет зависеть еще и от фазы луны. «Хочет — сделаем тут еще колонку». То есть получается даже на уровне тех же отчетов уникальность, которую при тиражировании на других заказчиков будет очень тяжело поддерживать.
Судя по тексту, описана итерационная разработка продукта по сути с нечеткими начальными требованиями. «Набросал каркас», «Не понравится — переделаю все бесплатно». В реальной жизни вообще такое очень редко бывает.
Вторая особенность, которая сквозит — это то, что речь о заказной разработке для одного конкретного заказчика. Без какого-либо обобщения такой подход по опыту не тиражируем на других заказчиков, где отчет будет зависеть еще и от фазы луны. «Хочет — сделаем тут еще колонку». То есть получается даже на уровне тех же отчетов уникальность, которую при тиражировании на других заказчиков будет очень тяжело поддерживать.
«Кроме того, я подвёл заказчика к мысли о том, что не нужно бросаться писать толмуды ТЗ, а имеет смысл сначала уточнить его потребности. Что, возможно, некоторые вещи будут значительно лучше, чем он рассчитывает, а некоторые ему совершенно не нужны и вместо них мы добавим действительно нужный функционал, но в любом случае, не стоит совершать необдуманных движений, и ТЗ мы будем делать вместе.»
Не всякий заказчик на это идёт, как ни убеждай. Впрочем, с ростом портфолио эта проблема нивелируется.
Не всякий заказчик на это идёт, как ни убеждай. Впрочем, с ростом портфолио эта проблема нивелируется.
Обязательно добиться того, чтобы заказчик определился с тем, чего он действительно хочет. Зачастую заказчик изначально приходит с мыслями «о зелёных кнопочках» и «фирменном логотипе на отчётах» и затрудняется сформулировать свои желания даже в общих чертах. Если не дать ему «созреть», то в результате может оказаться, что он хотел чего-то совсем другого или вообще ничего не хотел. Более того «созревший» заказчик, как правило, сильнее заинтересован в продукте и воспринимает его уже, как нечто реально существующее.
==============================
Ситуация: родилось ТЗ совместными усилиями, заказчик доволен. ТЗ подписано всеми сторонами, все хорошо. Проходит время, система уже готова к внедрению. Тут заказчик вспоминает «О! А это я забыл». Эта забывчивость может пройти мимо, а может очень аукнуться. Какова ваша реакция?
==============================
Ситуация: родилось ТЗ совместными усилиями, заказчик доволен. ТЗ подписано всеми сторонами, все хорошо. Проходит время, система уже готова к внедрению. Тут заказчик вспоминает «О! А это я забыл». Эта забывчивость может пройти мимо, а может очень аукнуться. Какова ваша реакция?
Именно для этого есть этапы макета и тестовой эксплуатации. У заказчика есть последний шанс что-то добавить/изменить. Иногда, если я предвижу подобное развитие событий, я специально ввожу этап тестовой эксплуатации, пишу «сырую» версию с базовым функционалом и настаиваю на том, чтобы заказчик с ней поработал. И даже притормаживаю разработку на некоторое время. То есть даю заказчику возможность окончательно определиться со своими запросами.
Спасибо за ответ.
Этапы есть, этапы пройдены. Остается буквально 3 недели до, так сказать, окончательного запуска (с начала календарного года кровь из носу). И тут появляется «хотелка/забывка». Варианты: запускаться без хотелки/забывки (плохой вариант) или за три недели поменять хорошую часть бизнес-логики и оттестировать.
Вот клянусь, не выдумываю, реальная ситуация. Просто интересна реакция человека с опытом.
Этапы есть, этапы пройдены. Остается буквально 3 недели до, так сказать, окончательного запуска (с начала календарного года кровь из носу). И тут появляется «хотелка/забывка». Варианты: запускаться без хотелки/забывки (плохой вариант) или за три недели поменять хорошую часть бизнес-логики и оттестировать.
Вот клянусь, не выдумываю, реальная ситуация. Просто интересна реакция человека с опытом.
да такое бывает. Тут нужно думать.
В идеале — по-моему, правильное решение — сказать заказчику, что данная доработка выходит за рамки изначально оговоренного проекта и требует значительных доработок и может быть сделана за дополнительную плату.
На практике иногда приходится срочно переделывать, чтобы ублажить заказчика, но он от этого иногда наглеет :)
Запускаться же нужно однозначно без «хотелок/забывалок». Иначе придётся долго доказывать, что не верблюд и до внесения изменений «мамой клянусь всё работало». Дорабатывать уже после запуска. Это поднимает авторитет в глазах клиента.
В идеале — по-моему, правильное решение — сказать заказчику, что данная доработка выходит за рамки изначально оговоренного проекта и требует значительных доработок и может быть сделана за дополнительную плату.
На практике иногда приходится срочно переделывать, чтобы ублажить заказчика, но он от этого иногда наглеет :)
Запускаться же нужно однозначно без «хотелок/забывалок». Иначе придётся долго доказывать, что не верблюд и до внесения изменений «мамой клянусь всё работало». Дорабатывать уже после запуска. Это поднимает авторитет в глазах клиента.
UFO just landed and posted this here
А я, вот, даже отвечу :) Ну, наверное какая-то работа у меня есть. Возможно она меня чем-то не устраивает? И наверное я действительно без труда найду работу. Проблемм в том, что я уже вырос из того возраста и состояния, когда можно сидеть и бездумно лабать что-то перед монитором и хочется найти интересную (или!) высокооплачиваемую работу.
Кажется мне, эта статья больше имеет отношение к работе бизнес-аналитика, по крайне мере та её часть, в которой рассказывается о выявлении требований, общении с заказчиком, нежели к управлению проектами.
Sap_ru, а были ли у Вас проблемы на этапе формирования требований и общении с заказчиками, к чему они приводили и из-за чего возникали? Или в Вашей практике только удачные проекты?
Sap_ru, а были ли у Вас проблемы на этапе формирования требований и общении с заказчиками, к чему они приводили и из-за чего возникали? Или в Вашей практике только удачные проекты?
Да там сплошные сложности — сложный и захватывающий процесс! :) И сложности возникали и продолжают возникают каждый раз :) Как их избегать я вроде рассказал — работать с заказчиком, смотреть, что на самом деле побудило его к этому заказу, смотреть на задачу со всех сторон :)
Вот и хотелось бы услышать поподробнее о сложностях и Ваших путях их преодаления. :)
А то в Вашей статье получается какой-то почти идеальный заказчик — цели его ясны, возможность общаться со всеми заинтересованными лицами есть, возможность тестировать на железе заказчика тоже есть, часть требований проясняется во время разработки — остаётся только вести разработку ПО с получением обратной связи от заказчика. Главное, как я понял, проблемм с коммуникациями нет. А где та грань, за которой Вы говорите заказчику, что с ним работать не будете?
PS
Если я вышел за рамки тематики статьи, то прошу извинить. =)
А то в Вашей статье получается какой-то почти идеальный заказчик — цели его ясны, возможность общаться со всеми заинтересованными лицами есть, возможность тестировать на железе заказчика тоже есть, часть требований проясняется во время разработки — остаётся только вести разработку ПО с получением обратной связи от заказчика. Главное, как я понял, проблемм с коммуникациями нет. А где та грань, за которой Вы говорите заказчику, что с ним работать не будете?
PS
Если я вышел за рамки тематики статьи, то прошу извинить. =)
Отличная статья, спасибо.
Главный месседж, который нужно уловить всем — это то, что программист-дизайнер должен сам какое-то время работать со своим продуктом! Не только проверять работоспособность при отладке, а именно долгое время, часами, сидеть и работать с данными.
Только этот способ приводит к появлению по-настоящему удобных программ.
Главный месседж, который нужно уловить всем — это то, что программист-дизайнер должен сам какое-то время работать со своим продуктом! Не только проверять работоспособность при отладке, а именно долгое время, часами, сидеть и работать с данными.
Только этот способ приводит к появлению по-настоящему удобных программ.
Статья великолепная, сразу видно профессионал.
Многое взял на заметку. Спасибо.
Многое взял на заметку. Спасибо.
Хороший, интересный пост.
Два вопроса:
1) По ходу текста сложилось впечатление, что автор потратил много времени и сил, пока заказчик созрел. Если это так, как Вы за это получили деньги? (делали бесплатно? / отдельной строкой в смете? / стоимость была размыта по остальным работам? ).
2) На сколько понял, это проект разработки и внедрения софта по существующим процессам. А есть же другая сторона медали, когда внедряется софт с «лучшими практиками». Были у Вас такие случаи? Как боролись с «сопротивлением персонала»?..
Два вопроса:
1) По ходу текста сложилось впечатление, что автор потратил много времени и сил, пока заказчик созрел. Если это так, как Вы за это получили деньги? (делали бесплатно? / отдельной строкой в смете? / стоимость была размыта по остальным работам? ).
2) На сколько понял, это проект разработки и внедрения софта по существующим процессам. А есть же другая сторона медали, когда внедряется софт с «лучшими практиками». Были у Вас такие случаи? Как боролись с «сопротивлением персонала»?..
Да, это было специально. И бесплатно. Это не требовало много сил. Несколько раз встретиться с заказчиком. Почитать его предложения. Изложить свои. Если какие-то силы и тратятся, то моральные. Зато растёт коммуникативный скил и налаживаются отношения с потенциальным работодателем. По времени это тоже не затратно. Максимум — сесть прикинуть возможности и варианты, а это в любом случае нужно делать. Параллельно можно работать над чем-то ещё.
По второму пункту не совсем понял. Можно сказать это и были «лучшие практики», так как предлагаемое (и сделанное) значительно отличалось от того к чему привык персонал. Но так как пожелания персонала выслушивались, вносились некоторые изменения, да, и вообще, много времени тратилось на обучение, то всё всегда проходило гладко. Как я написал оптимальный путь — найти толковых людей и обучить их. Заодно обкатать способы обучения и внедрения. Обученных, затем привлекать к процессу обучения остальных. Были случаи явного саботажа (причина — в результате автоматизации, как правило, усиливается контроль и перекрываются возможности дял всяческих махинаций) в таких случаях действовал через начальство. Иногда приходилось идти по цепочке вверх (непосредственное начальство оказывало «повязанным» со своими подчинёнными), до тех пор пока не находил человека, заинтересованного в улаживании конфликта. Иногда приходилось уговаривать начальство не наказывать подчинённых. Короче говоря лично я считаю, что нужно налаживать отношения с коллективом, но без панибратства и в случае конфликтов не бояться обсуждать их с заказчиком. Был очень показательный пример. Там, где есть кассовая техника (особенно на заправках) иногда обильно процветает мухлёж с кассовыми чеками. Мухлёжь совершенно безобидный для клиентов и практически законный. Более того, он даже несколько поднимает пристиж и привлекательность организации. Начальство ничего об этом не знало. После внедрения нового софта мухлёжь стал не возможен. Начался тихий саботаж со стороны работников. Пришлось долго и нудно разбираться пока понял, что проблема создаётся специально и в чём истинная её суть. Дальше пошёл к начальству изложил суть вопроса. Первой реакцией заказчика было «Всех уволю!». Пришлось вступиться за сотрудников и объяснить, что возможно имеет смысл не запрещать, а взять под контроль. Сошлись на том, что была добавлена ограниченная возможность для мухлежа и новые отчёты. Заказчик провёл воспитательную беседу с подчинёнными и указал рамки в которых он будет закрывать глаза. Это сильно оздоровило коллектив и сняло проблему. Правда, месяца через три ему всё таки пришлось показательно уволить двух человек.
По второму пункту не совсем понял. Можно сказать это и были «лучшие практики», так как предлагаемое (и сделанное) значительно отличалось от того к чему привык персонал. Но так как пожелания персонала выслушивались, вносились некоторые изменения, да, и вообще, много времени тратилось на обучение, то всё всегда проходило гладко. Как я написал оптимальный путь — найти толковых людей и обучить их. Заодно обкатать способы обучения и внедрения. Обученных, затем привлекать к процессу обучения остальных. Были случаи явного саботажа (причина — в результате автоматизации, как правило, усиливается контроль и перекрываются возможности дял всяческих махинаций) в таких случаях действовал через начальство. Иногда приходилось идти по цепочке вверх (непосредственное начальство оказывало «повязанным» со своими подчинёнными), до тех пор пока не находил человека, заинтересованного в улаживании конфликта. Иногда приходилось уговаривать начальство не наказывать подчинённых. Короче говоря лично я считаю, что нужно налаживать отношения с коллективом, но без панибратства и в случае конфликтов не бояться обсуждать их с заказчиком. Был очень показательный пример. Там, где есть кассовая техника (особенно на заправках) иногда обильно процветает мухлёж с кассовыми чеками. Мухлёжь совершенно безобидный для клиентов и практически законный. Более того, он даже несколько поднимает пристиж и привлекательность организации. Начальство ничего об этом не знало. После внедрения нового софта мухлёжь стал не возможен. Начался тихий саботаж со стороны работников. Пришлось долго и нудно разбираться пока понял, что проблема создаётся специально и в чём истинная её суть. Дальше пошёл к начальству изложил суть вопроса. Первой реакцией заказчика было «Всех уволю!». Пришлось вступиться за сотрудников и объяснить, что возможно имеет смысл не запрещать, а взять под контроль. Сошлись на том, что была добавлена ограниченная возможность для мухлежа и новые отчёты. Заказчик провёл воспитательную беседу с подчинёнными и указал рамки в которых он будет закрывать глаза. Это сильно оздоровило коллектив и сняло проблему. Правда, месяца через три ему всё таки пришлось показательно уволить двух человек.
Если есть возможность, расскажите поподробнее как решали вопрос с воровством на кассах и какой вид мухлежа присутствовал.
вопрос с воровством решается правильной отчётностью :) А если заказчик не может или не хочет наводить порядок со своими сотрудниками — то очертить зону ответственности. Я же не Мать Тереза, чтобы все его проблемы решать :) Моё дело предупредить.
А с чеками махинаций много бывает. Самая простая — не отдавать чек, если не просят и давать потом клиентам чек на бОльшую сумму. Можно начинать бить чек, а потом сразу аннулировать его — все законно, а клиента остаётся нормальный чек (нет последней строки в чеке, но это редко кто замечает).
Иногда вообще бьют нормальный чек и оформляют продажу, а затем делают отмену продажи и бьют чек возврата. У клиента остаётся совершенно нормальный чек. Нужно, конечно, заносить в журнал и писать объяснения, но это себя окупает.
А с чеками махинаций много бывает. Самая простая — не отдавать чек, если не просят и давать потом клиентам чек на бОльшую сумму. Можно начинать бить чек, а потом сразу аннулировать его — все законно, а клиента остаётся нормальный чек (нет последней строки в чеке, но это редко кто замечает).
Иногда вообще бьют нормальный чек и оформляют продажу, а затем делают отмену продажи и бьют чек возврата. У клиента остаётся совершенно нормальный чек. Нужно, конечно, заносить в журнал и писать объяснения, но это себя окупает.
Способы мне известны, но вот решение… помогает вешать веб-камеру, но это до поры до времени. Какие же именно вопросы с мошенничеством были решены при внедрении? Ведь никакая отчетность не поможет, если кассир не пробил чек, в фискальнике — нет данных, нет претензий, деньги уже в кармане…
Конкретно там — поставили девайс, отображающий содержимое экрана охране и пишущий его циклически неделю. Но это для того, чтобы не воровали и не обсчитывали клиентов. С чеками добавили специальные отчёты для начальства по сомнительным операциям и аннулированным чеками.
Не пробил чек — такого не бывает. Это как раз решается программно. Нет чека — нет дальнейшей работы. Более того, формально, по-другому и работать нельзя.
Не пробил чек — такого не бывает. Это как раз решается программно. Нет чека — нет дальнейшей работы. Более того, формально, по-другому и работать нельзя.
Возврат на АЗС — звучит удивительно.
Это типа: «Я передумал.., скачайте ваш бензин обратно»? :)
Это типа: «Я передумал.., скачайте ваш бензин обратно»? :)
Заказчик заказчику рознь, в данном примере это был вменяемый человек, скорее всего один. Чаще всего заказчик — это группа людей, толком не контактирующих друг с другом и имеющих разные цели. Чаще всего это не очень обязательные люди или достаточно занятые. Чаще всего, крупный проект с нечетким техзаданием закончится конкретным минусом в балансе у исполнителя либо доход/затраченное время выглядит смехотворной суммой.
Я не критикую данный подход, он очень хорошо работает, когда удается подружиться и когда все на доверии, но не иначе.
Я не критикую данный подход, он очень хорошо работает, когда удается подружиться и когда все на доверии, но не иначе.
Может у Вас еще был опыт работы с государством?
ТЗ регламентировано ГОСТом, четкой формулировки задачи от заказчика нет (какое дело Большому Начальнику до всяких мелочей, вы дело делайте), а у пользователей нет ни времени, ни понимания, что нужно делать.
И да, спасибо за статью!
ТЗ регламентировано ГОСТом, четкой формулировки задачи от заказчика нет (какое дело Большому Начальнику до всяких мелочей, вы дело делайте), а у пользователей нет ни времени, ни понимания, что нужно делать.
И да, спасибо за статью!
У меня есть опыт.
1) Выявляем всех заинтересованных в проекте. Встречаемся с ними. Собираем что можем от них получить
2) Пишем ТЗ где сами все формулируем.
3) Согласовываем — это самое интересное
4) Большой начальник утверждает ТЗ и ответственного со стороны заказчика
это такой чистоплюйский список шагов по сбору требований у госзаказчика
1) Выявляем всех заинтересованных в проекте. Встречаемся с ними. Собираем что можем от них получить
2) Пишем ТЗ где сами все формулируем.
3) Согласовываем — это самое интересное
4) Большой начальник утверждает ТЗ и ответственного со стороны заказчика
это такой чистоплюйский список шагов по сбору требований у госзаказчика
Пробелов бы после точек в статье понаставить, местами их не хватает… :(
Если не секрет — расскажите плз. в каком виде вы ведете список требований собираемых из большого количества источников? Как формализуете и выбираете действительно важные?
Что-то вроде:
Заметки в блокнот, потом эксель + многократное изучение собранного и ранжирование?
Или как-то еще?
ps: спасибо за отличную статью, особенно интересно т.к. это живой опыт.
Что-то вроде:
Заметки в блокнот, потом эксель + многократное изучение собранного и ранжирование?
Или как-то еще?
ps: спасибо за отличную статью, особенно интересно т.к. это живой опыт.
Сначала выделаю самое важно — то, что будет определять функционал, сложность и структуру. Затем выделаю то, что может повлиять на сложность — кол-во отчётов, спорные моменты, по которым заказчик может передумать и т.п. Затем всё это обрастает деталями. Внешне оформлено, как куча бумажек с записями на основании которых пишу листок с древовидной структурой требований и вопросов по проекту (с картинками). Несколько раз это все переписываю. В конце пишу на компьютере документ, описывающий структуру проекта. Иногда, вплоть до описания внутренних интерфейсов и представления данных. Ну, а дальше — ТЗ и согласование с заказчиком.
Хочу спросить совета у сообщества читателей.
Есть похожий опыт сбора требований, описания задач и в дальнейшем внедрения разработанного ПО (работа в отделе внедрения в большом интеграторе).
Сам вопрос: есть ли шанс найти приложение таких навыков в команде фрилансеров?
Или такие навыки востребованы только при работе «на дядю»?
Есть похожий опыт сбора требований, описания задач и в дальнейшем внедрения разработанного ПО (работа в отделе внедрения в большом интеграторе).
Сам вопрос: есть ли шанс найти приложение таких навыков в команде фрилансеров?
Или такие навыки востребованы только при работе «на дядю»?
Sign up to leave a comment.
О работе с заказчиками, разработке и внедрении софта