Как стать автором
Обновить

Комментарии 52

Занимаюсь чем-то схожим, но автоматизирую технологические процессы.
Если не секрет, сколько человекочасов заняло создание такого программного продукта? А какая платформа использовалась? (C++/C#/Java/Oracle/Web server+язык/?).
Пол года. Три месяца до рабочего макета. Ещё два месяца до финальной версии и месяц — на доводку. Писалось в свободное время.
Использовался Delphi. Ибо позволяет достичь максимального результата за минимальные сроки при минимальном уродовании. В будущем буду использоваться Java. C++ — слишком трудоёмко, негибко и не удобно для визуализации. .Net на тот момент была тёмной лошадкой со странными перспективами.
Ах да, интересное замечание — в качестве сервера баз данный был выбран Interbase (firefox). Т.к. по личным наблюдения только он может пять лет работать без обслуживания на офисном компьютере, который даже выключают иногда прямо пилотом, и не нарушить целостность базы. Всё остальное или стоило много денег, или (как например MySQL и иже с ним) не обеспечивало надёжности и отказоустойчивости.
Видимо, Firebird, а не Firefox
Да, конечно :) В момент написания упорно вспоминал, где видел плагин к firefox для удобного написания постов в хабр :)
Как оценивали стоимость проекта? Просто торговались исходя из цены на рынке или как то измеряли и обосновывали?

Ваш рассказ — хороший пример того, как помогает проекту грамотный системный и бизнес-анализ.
Ну, прежде всего это был далеко не первый мой подобный проект и цены я приблизительно знал. Но конкретно тот проект оценивал сугубо из здравого смысла — желаемая зарплата помноженная на время работы. В некотором роде продешевил, но, во-первых, заказчик остался счастлив, а, во-вторых, реальная трудоёмкость и загрузка были далеко не 100% — после установки пробной версии работать приходилось лишь время от времени :)
С учетом того, что вы делали программу, а не продукт ( так следует из вашей статьи ) — это настоящая success story. Когда не надо жертвовать никакими требованиями пользователя — работаешьь с заказчиком душа в душу
Вы описали случай разработки системы одним человеком. А может у Вас есть опыт командной разработки?

В первую очередь интересует вопрос распределения обязанностей между членами команды: должен ли общаться с заказчиком только один человек (а-ля team manager) или каждый разрабочик должен общаться по вопросам области его ответственности?
Такой опыт тоже есть. Хотя и меньший. Как негативный так и позитивный.
Главное — чёткое разделение ролей и субординация.
С заказчиком должен общаться один человек. Если есть необходимость чтобы общались несколько, то должно быть чёткое разграничение области компетенции. В любом случае любые обещания должен давать и согласовывать один человек — нарушение этого правила погубило несколько проектов.
Обязательно должен быть человек с правом решающего голоса. Так как иногда на ровном месте возникают споры по пустяку — должен быть однозначный способ разрешения таких ситуаций.
Возможно, когда-нибудь, изложу негативный и очень поучительный опыт работы в команде :)
Изложите обязательно, это будет интересно почитать
Как видно из статьи, автор уделяет большое внимание управлению требованиями. Это очень грамотная позиция.
По моему мнению, правильное управление требованиями — один из ключевых факторов успеха проекта и снижения рисков при разработке.
Классный текст, подпишусь почти под каждым словом.

Особенно верно на счет длинных мануалов, которые обычно требуют писать «шоб было». Самый верный мануал — это лист A4 (бумажный!) с Quick Start гайдом, в котором написано как запустить, залогиниться, создать что\то (документ\запись\счет), сохранить, открыть, отредактировать. Всё! Больше листа А4 читать никто не будет.

Еще — обязательно хот-кеи! Вам кажется что у Вас в ПО классные и логичные кнопки, есть контекстные менюшки и в главном меню хорошая структура? Люди будут работать в этом годами! Каждое действие, на которое нет хоткея — это минус 1-2 секунды. На 1000 раз в день. На годы работы. Понимаете, сколько Вы людям сэкономите времени жизни? Система хот-кеев, к стати, должна быть настраиваемой. Вы понятия не имеете, как юзеру удобно.
Очень хорошо, но, к сожалению, мало применимо к удалённой работе.
НЛО прилетело и опубликовало эту надпись здесь
Сдаётся, слышу я ехидство в Вашем тоне… 11 лет и несколько десятков проектов пойдёт? Кому интересно — без проблем найдут мое резюме. И я категорически отказываюсь флудить по этому поводу.
НЛО прилетело и опубликовало эту надпись здесь
В посте описан по сути очередной «Опердень» как класс задач. Кстати, интересно, что продукт покрывал автоматизацией? какую область деятельности?

Судя по тексту, описана итерационная разработка продукта по сути с нечеткими начальными требованиями. «Набросал каркас», «Не понравится — переделаю все бесплатно». В реальной жизни вообще такое очень редко бывает.

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

С вашего позволения сейчас отвечу дополнением к посту
«Кроме того, я подвёл заказчика к мысли о том, что не нужно бросаться писать толмуды ТЗ, а имеет смысл сначала уточнить его потребности. Что, возможно, некоторые вещи будут значительно лучше, чем он рассчитывает, а некоторые ему совершенно не нужны и вместо них мы добавим действительно нужный функционал, но в любом случае, не стоит совершать необдуманных движений, и ТЗ мы будем делать вместе.»

Не всякий заказчик на это идёт, как ни убеждай. Впрочем, с ростом портфолио эта проблема нивелируется.
Обязательно добиться того, чтобы заказчик определился с тем, чего он действительно хочет. Зачастую заказчик изначально приходит с мыслями «о зелёных кнопочках» и «фирменном логотипе на отчётах» и затрудняется сформулировать свои желания даже в общих чертах. Если не дать ему «созреть», то в результате может оказаться, что он хотел чего-то совсем другого или вообще ничего не хотел. Более того «созревший» заказчик, как правило, сильнее заинтересован в продукте и воспринимает его уже, как нечто реально существующее.
==============================
Ситуация: родилось ТЗ совместными усилиями, заказчик доволен. ТЗ подписано всеми сторонами, все хорошо. Проходит время, система уже готова к внедрению. Тут заказчик вспоминает «О! А это я забыл». Эта забывчивость может пройти мимо, а может очень аукнуться. Какова ваша реакция?
Именно для этого есть этапы макета и тестовой эксплуатации. У заказчика есть последний шанс что-то добавить/изменить. Иногда, если я предвижу подобное развитие событий, я специально ввожу этап тестовой эксплуатации, пишу «сырую» версию с базовым функционалом и настаиваю на том, чтобы заказчик с ней поработал. И даже притормаживаю разработку на некоторое время. То есть даю заказчику возможность окончательно определиться со своими запросами.
Спасибо за ответ.

Этапы есть, этапы пройдены. Остается буквально 3 недели до, так сказать, окончательного запуска (с начала календарного года кровь из носу). И тут появляется «хотелка/забывка». Варианты: запускаться без хотелки/забывки (плохой вариант) или за три недели поменять хорошую часть бизнес-логики и оттестировать.

Вот клянусь, не выдумываю, реальная ситуация. Просто интересна реакция человека с опытом.
да такое бывает. Тут нужно думать.
В идеале — по-моему, правильное решение — сказать заказчику, что данная доработка выходит за рамки изначально оговоренного проекта и требует значительных доработок и может быть сделана за дополнительную плату.
На практике иногда приходится срочно переделывать, чтобы ублажить заказчика, но он от этого иногда наглеет :)
Запускаться же нужно однозначно без «хотелок/забывалок». Иначе придётся долго доказывать, что не верблюд и до внесения изменений «мамой клянусь всё работало». Дорабатывать уже после запуска. Это поднимает авторитет в глазах клиента.
Спасибо
НЛО прилетело и опубликовало эту надпись здесь
А я, вот, даже отвечу :) Ну, наверное какая-то работа у меня есть. Возможно она меня чем-то не устраивает? И наверное я действительно без труда найду работу. Проблемм в том, что я уже вырос из того возраста и состояния, когда можно сидеть и бездумно лабать что-то перед монитором и хочется найти интересную (или!) высокооплачиваемую работу.
НЛО прилетело и опубликовало эту надпись здесь
Кажется мне, эта статья больше имеет отношение к работе бизнес-аналитика, по крайне мере та её часть, в которой рассказывается о выявлении требований, общении с заказчиком, нежели к управлению проектами.

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

А то в Вашей статье получается какой-то почти идеальный заказчик — цели его ясны, возможность общаться со всеми заинтересованными лицами есть, возможность тестировать на железе заказчика тоже есть, часть требований проясняется во время разработки — остаётся только вести разработку ПО с получением обратной связи от заказчика. Главное, как я понял, проблемм с коммуникациями нет. А где та грань, за которой Вы говорите заказчику, что с ним работать не будете?

PS
Если я вышел за рамки тематики статьи, то прошу извинить. =)
Отличная статья, спасибо.
Главный месседж, который нужно уловить всем — это то, что программист-дизайнер должен сам какое-то время работать со своим продуктом! Не только проверять работоспособность при отладке, а именно долгое время, часами, сидеть и работать с данными.

Только этот способ приводит к появлению по-настоящему удобных программ.
Статья великолепная, сразу видно профессионал.

Многое взял на заметку. Спасибо.
Хороший, интересный пост.

Два вопроса:
1) По ходу текста сложилось впечатление, что автор потратил много времени и сил, пока заказчик созрел. Если это так, как Вы за это получили деньги? (делали бесплатно? / отдельной строкой в смете? / стоимость была размыта по остальным работам? ).

2) На сколько понял, это проект разработки и внедрения софта по существующим процессам. А есть же другая сторона медали, когда внедряется софт с «лучшими практиками». Были у Вас такие случаи? Как боролись с «сопротивлением персонала»?..
Да, это было специально. И бесплатно. Это не требовало много сил. Несколько раз встретиться с заказчиком. Почитать его предложения. Изложить свои. Если какие-то силы и тратятся, то моральные. Зато растёт коммуникативный скил и налаживаются отношения с потенциальным работодателем. По времени это тоже не затратно. Максимум — сесть прикинуть возможности и варианты, а это в любом случае нужно делать. Параллельно можно работать над чем-то ещё.
По второму пункту не совсем понял. Можно сказать это и были «лучшие практики», так как предлагаемое (и сделанное) значительно отличалось от того к чему привык персонал. Но так как пожелания персонала выслушивались, вносились некоторые изменения, да, и вообще, много времени тратилось на обучение, то всё всегда проходило гладко. Как я написал оптимальный путь — найти толковых людей и обучить их. Заодно обкатать способы обучения и внедрения. Обученных, затем привлекать к процессу обучения остальных. Были случаи явного саботажа (причина — в результате автоматизации, как правило, усиливается контроль и перекрываются возможности дял всяческих махинаций) в таких случаях действовал через начальство. Иногда приходилось идти по цепочке вверх (непосредственное начальство оказывало «повязанным» со своими подчинёнными), до тех пор пока не находил человека, заинтересованного в улаживании конфликта. Иногда приходилось уговаривать начальство не наказывать подчинённых. Короче говоря лично я считаю, что нужно налаживать отношения с коллективом, но без панибратства и в случае конфликтов не бояться обсуждать их с заказчиком. Был очень показательный пример. Там, где есть кассовая техника (особенно на заправках) иногда обильно процветает мухлёж с кассовыми чеками. Мухлёжь совершенно безобидный для клиентов и практически законный. Более того, он даже несколько поднимает пристиж и привлекательность организации. Начальство ничего об этом не знало. После внедрения нового софта мухлёжь стал не возможен. Начался тихий саботаж со стороны работников. Пришлось долго и нудно разбираться пока понял, что проблема создаётся специально и в чём истинная её суть. Дальше пошёл к начальству изложил суть вопроса. Первой реакцией заказчика было «Всех уволю!». Пришлось вступиться за сотрудников и объяснить, что возможно имеет смысл не запрещать, а взять под контроль. Сошлись на том, что была добавлена ограниченная возможность для мухлежа и новые отчёты. Заказчик провёл воспитательную беседу с подчинёнными и указал рамки в которых он будет закрывать глаза. Это сильно оздоровило коллектив и сняло проблему. Правда, месяца через три ему всё таки пришлось показательно уволить двух человек.
Если есть возможность, расскажите поподробнее как решали вопрос с воровством на кассах и какой вид мухлежа присутствовал.
вопрос с воровством решается правильной отчётностью :) А если заказчик не может или не хочет наводить порядок со своими сотрудниками — то очертить зону ответственности. Я же не Мать Тереза, чтобы все его проблемы решать :) Моё дело предупредить.
А с чеками махинаций много бывает. Самая простая — не отдавать чек, если не просят и давать потом клиентам чек на бОльшую сумму. Можно начинать бить чек, а потом сразу аннулировать его — все законно, а клиента остаётся нормальный чек (нет последней строки в чеке, но это редко кто замечает).
Иногда вообще бьют нормальный чек и оформляют продажу, а затем делают отмену продажи и бьют чек возврата. У клиента остаётся совершенно нормальный чек. Нужно, конечно, заносить в журнал и писать объяснения, но это себя окупает.
Способы мне известны, но вот решение… помогает вешать веб-камеру, но это до поры до времени. Какие же именно вопросы с мошенничеством были решены при внедрении? Ведь никакая отчетность не поможет, если кассир не пробил чек, в фискальнике — нет данных, нет претензий, деньги уже в кармане…
Конкретно там — поставили девайс, отображающий содержимое экрана охране и пишущий его циклически неделю. Но это для того, чтобы не воровали и не обсчитывали клиентов. С чеками добавили специальные отчёты для начальства по сомнительным операциям и аннулированным чеками.
Не пробил чек — такого не бывает. Это как раз решается программно. Нет чека — нет дальнейшей работы. Более того, формально, по-другому и работать нельзя.
Кода работа (типа запуск налива бензина) управляется той же программой — это решение, угу. А вот когда работа — это вручную что-то выдать с полки или вовсе услугу оказать типа чистки ботинок — вот тут вопросы остаются.

это я не то чтоб вопрос Вам задаю, это я так, соображения по поводу…
Возврат на АЗС — звучит удивительно.
Это типа: «Я передумал.., скачайте ваш бензин обратно»? :)
Нет. Например пробили чек, а в бак не влезло :) Или клиент ошибся с выбором топлива, а потом передумал :)
Учитывая, что формально чек должен быть пробит до заправки — ситуация нормальная.
Заказчик заказчику рознь, в данном примере это был вменяемый человек, скорее всего один. Чаще всего заказчик — это группа людей, толком не контактирующих друг с другом и имеющих разные цели. Чаще всего это не очень обязательные люди или достаточно занятые. Чаще всего, крупный проект с нечетким техзаданием закончится конкретным минусом в балансе у исполнителя либо доход/затраченное время выглядит смехотворной суммой.

Я не критикую данный подход, он очень хорошо работает, когда удается подружиться и когда все на доверии, но не иначе.
Совершенно согласен. Если у заказчик представляет собой несколько слабосвязанных человек, то проблем нужно ждать в любом случае :)
Может у Вас еще был опыт работы с государством?
ТЗ регламентировано ГОСТом, четкой формулировки задачи от заказчика нет (какое дело Большому Начальнику до всяких мелочей, вы дело делайте), а у пользователей нет ни времени, ни понимания, что нужно делать.

И да, спасибо за статью!
У меня есть опыт.
1) Выявляем всех заинтересованных в проекте. Встречаемся с ними. Собираем что можем от них получить
2) Пишем ТЗ где сами все формулируем.
3) Согласовываем — это самое интересное
4) Большой начальник утверждает ТЗ и ответственного со стороны заказчика

это такой чистоплюйский список шагов по сбору требований у госзаказчика

Пробелов бы после точек в статье понаставить, местами их не хватает… :(
Дык, парсер, как известно — лох. Были пробелы.
Если не секрет — расскажите плз. в каком виде вы ведете список требований собираемых из большого количества источников? Как формализуете и выбираете действительно важные?

Что-то вроде:
Заметки в блокнот, потом эксель + многократное изучение собранного и ранжирование?
Или как-то еще?

ps: спасибо за отличную статью, особенно интересно т.к. это живой опыт.
Сначала выделаю самое важно — то, что будет определять функционал, сложность и структуру. Затем выделаю то, что может повлиять на сложность — кол-во отчётов, спорные моменты, по которым заказчик может передумать и т.п. Затем всё это обрастает деталями. Внешне оформлено, как куча бумажек с записями на основании которых пишу листок с древовидной структурой требований и вопросов по проекту (с картинками). Несколько раз это все переписываю. В конце пишу на компьютере документ, описывающий структуру проекта. Иногда, вплоть до описания внутренних интерфейсов и представления данных. Ну, а дальше — ТЗ и согласование с заказчиком.
Хочу спросить совета у сообщества читателей.
Есть похожий опыт сбора требований, описания задач и в дальнейшем внедрения разработанного ПО (работа в отделе внедрения в большом интеграторе).
Сам вопрос: есть ли шанс найти приложение таких навыков в команде фрилансеров?
Или такие навыки востребованы только при работе «на дядю»?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории