Правильная (честная) и работающая экономика разработки софта

Может быть немного сумбурненько, но чукча не писатель, а фиксатор фактов.

UPD3: Это идет изложение уже существующей методики по которой идет работа. В статье факты а не домыслы.

Спарк хорошее место для дискуссий поэтому давайте поучу вас работать, а то и не зажигательные статейки зачастили тут.

Удаленная работа это не фриланс.

То что ты берешь в работу заказ на текущих биржах торгуясь до того как формализовал все детали работ (результатов работ) на основании некоего технического документа с открытой возможностью вносить правки при приемке - поздравляю, тут ты свалился в пропасть выполнения поручений, ты теперь порученный, паспарту.

Теперь ты выполняшь все что тебе скажут до состояния пока "хозяин" не примет по своему усмотрению что он “достаточно тебя попользовал” по своему личному мнениию конечно же. А это как всегда будет точно много итераций, потому что в этом и есть “пользование” тебя по его ущербному мышлению.

Выполняя проектные работы мы четко понимаем что работаем мы на результат, неважно в какой структуре мы находимся - внутри команды или в конструкции открытого рынка. Все равно измерять готовность финальный заказчик будет по факту своего внутреннего ощущения что он "получил" то что нужно от вас.

Поэтому ориентриоваться нужно (и осмечивать) результат.

Проблема в разработке ПО на сегодня в том что факт работ над продуктом сейчас измеряется как поручение до состояния "я принимаю" мне это подходит, а фактическая трата идет по часам (и расходникам).

Час сидения на заднице и час сделанного результата который прошел в приемку - это два разных набора работ раз, два это как всегда различный объем работ - 90% уже выполненных работ в таком формате сжигается для "осознания" конечным бенефициаром в "измеряемой плоскости продукта" что ему нужно на самом деле.

Выматывая вас он на этом учится - то есть есть проблема с воображением и представлением конечного результата в голове у клиента, поэтому фактически проблема двухстороння - клиенту действительно нужно четко понимать что в результате будет.

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

Нужно четко разделять - если клиент не хочет работать с вами "об прототипы", делая их вы утвреждаете что каждая следующая переделка результата (правка) без прототипирования будет за счет клиента.

Если он действительно не понимает по распечатанным экранам что будут происходить в реальном продукте - указываете что вы сделаете как считаете нужным, а клиент это все оплачивает без оговорок.

Все последующие правки за его счет. Если он такой биг-босс - то он это оплачивает.

Теперь про поручения - когда ты работаешь отталкиваясь от такой фактуры ты не специалист - ты наемный рабочий, поздравляю.

Специалист это тот кто понимает то что он делает и как он это делает. Если ты это понимаешь (можешь формулировать) - ты можешь это предъявить на носителе и схемах. Если ты не понимаешь этого - ты мычишь что тут много деталей, и проваливаешься в работу с правочками и поручениями.

Отсутствие четкого понимания что будет в результате работ и сколько это стоит сваливает вас в почасовку.

А по результату работать дешевле для бизенса и прибыльней для фрилансера / студии - вы можете сделать не за 40 часов а за три часа, но приложив усилия вы сделаете результат эквиваленный вашим старым замерам про 40 часов.

Что что такое результат в моем предствалении - это именно то, что клиент может от вас "забрать" себе и этим пользоваться.

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

Именно поэтому битриксы обесценивают свои (и твои) же возможности продавая их оптом. Ребята собрали продукт и круто - во-первых нормальные бизнесы с нормально описанной деятельностью двигаются со скоростью света от битрикса в свои разработки, потому что майнтанить решение сделанное под свои задачи в сотни раз дешевле чем заниматься доработкой на чужих “надстройках”.

Я предлагаю работу в формате "сметы" - то есть сколько вы сделали результатов по запросу, столько и будет стоить конечный продукт который он себе "забирает", измеряемый по элементам / компонентам.

Когда начинается работа мы фиксируем бюджет проекта, получаем предоплату, и всегда придерживаемся расчетной схемы что на то что у нас произойдет сверка "полученных" по факту продуктов как результатов работ, в конце которой мы сделаем соглашение о том в чью сторону перейдут остаточные средства. Если вы сделали больше чем вам внесли - вы получаете доплату. Если вы сделали меньше чем вам заплатили - вы возвращаете остаток, либо идете в новую итерацию "правок".

Такая вот экономика в двух словах - работа и оплата за результат.

Результат - это то что нужно клиенту. То чем он сможет пользоваться. Он может это заказать и когда это увидит он осознает весь окружающий себя мир - куда он это воткнет, как это будет работать, как мы будем что-то с этим делать.

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

Проблема в том что об этом начинают думать только после того как получили продукт и подписали акты (в лучшем случае) или же в момент приемки что чаще (в худшем случае). Всегда проблема одна - результат не тот.

Так как сотрудничают две стороны - классическая ситуация в том что начинаются поиски виноватых почему кто-то и что-то не сделал. Идет возврат денег или же неполучения того нужного результата клиентом.

Я долго бился над этой проблемой и в итоге у меня четко выработалась картина как нужно поступать - нужно разобрать по косточкам ту часть деятельности в которую клиент предполагает "втыкать" новый софт и помочь ему связать это с его целями, наглядно показав что его решение скорее всего не решение а усложнение ситуации, и что настоящее решение может быть отказ от куска этой деятельности (или оптимизации) и в сокращении затрат на нужную разработку (внедрение).

В этот момент мы можем расставить опорные точки в тех местах от которых будет строится вся работа над архитектурой решения - и черт возьми она будет сразу понятна клиенту и он с удовольствием ее подпишет.

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

1. Аналитика - Обработка и анализ входящих материалов на предмет определения ключевых альф системы и продуктов
2. Инженерия требований - Проработка, трассировка и согласование выявленных требований к системе
3. Владение продуктом - Определение для чего и какая нужна система, распоряжение и заказ ее изготовления
4. Онтология - Работа с предметной областью, наполнение тезауруса и онтологии (отношений в мире) проекта
5. Рабочее проектирование - Детальная проектировка решения в виде макетов состояний с описью элементов
6. Веб разработка - Программирование и сборка веб продуктов
7. Мобильная разработка - Программирование и сборка мобильных продуктов
8. Дизайн - Формирование внешнего облика и стиля спроектированных компонентов, формирование брендбука.
9. Руководство разработкой - Обеспечение производства рабочих продуктов, формирование и сопровождение выпусков продукта
10. Секретариат - Формальное протоколирование и доведение до всех участников переговоров, созвонов, рабочих встреч, контроль актуальности документации и управление параметрами проекта в воркшопе.
11. Стейкхолдер системы - Заинтересованное в изготовленной системе лицо. Владелец интересов по отношению к целевой системе. Интересы именуются как цели к достижению в рамках совместных работ.

И как мы можем видеть что для многих видимая часть работ это уже конечный продукт в который можно "потыкать пальцем", но появится он только в результате сборки (программирования) и доставки в проверяемую среду.

Проблема заключается в том что весь успех проекта сосредоточен на аналитических и формализационных этапах. В моей цепочке работ - кодирование это уже билд / сборка. Я уверен в ближайшем будущем системы проектирования будут сильно развиты так что мы будем заниматься только проектировкой и сборка будет идти автоматически на нужной платформе (target). Но сейчас я не об этом.

Из-за того что у вас (как правило) не видно всего того что вы делаете а что не делаете в рамках аналитических работ (нет потока промежуточных артефактов) - вы несете свои убытки, не можете аргументировать расходную часть и получать за это деньги, и не можете вовлечь клиента в совместную работу по этой теме потому что обычно "на словах" это не получается, и один несчастный документ Word для команды не содержит всю цепочку связанных ключевых информационных объектов, не поддерживается жизненный цикл и тд.

Точно также вы не можете назвать цену в 150 тыс рублей за час, ведь если вы подготовили все заранее, спроектировали какое-то решение, и на основе этих решений сделали сборку - цена этих решений должна быть по “получаемым возможностям” которые нужны клиенту.

То есть детальная формализация крайне важна и нужна, все это давно понимают но никто не понимает как это сделать. Если вести учет документа - то эти документы к вечеру все нужно переписывать и пере-согласовывать - все бегут от этого как от огня.

А если представить что вы имеете на руках точную смету компонентов которые понятны и полезны клиенту, вы можете выдать ему смету цифру - спокойно сделать именно то что задокументировано и "правки" внесены в проект до начала работ - вы же обретаете возможность контроля хода работ, планирования сроков и увеличение бюджетов при экономии клиентских денег.

Сразу оговорюсь как считаются результаты: компонентами, а компоненты по элементам. Количество состояний + размещения. Описываются в виде юз кейсов для тестирования.

Коротко что значит сделать - при нормальной работе сделать это значит изготовить в соответсвии с тем описанием результата о каком договаривались.

Но если в результате можно найти то что было ранее написано и однозначно соотнести это с финальным результатом - тогда получается что результат очень даже похож на то что вы договорились делать, не так ли?

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

Что такое успешно - успешно это когда есть результат (рабочий продукт) и он полезен клиенту.

На этот вопрос отвечает системная инженерия - мы фиксируем, потом согласуем целевую схему, потом мы пишем требования, потом требования размещаем в архитектуре, делаем рабочие продукты и получаем выход.

Об этом отдельные посты.

Тезисно о формализации

Очевидно - это “очами видно”. Как вы понимаете "очами" можно увидеть только то что записано в документ и изображено на схемах.

Проблема в том что на так называемое "очевидно же" вы не можете указать пальцем в случае спора и показать разницу.

Многие хорошо понимают проблему что хотя бы раза три задокументировать успешно в тз что-то чтобы не было после этого правок и различного толкования - и вообще пробовали ли вы это сделать вообще больше трех раз успешно чтобы без правочек?

Создаваемые документы рашеют задачу - указать на что-то пальцем в момент проверки результата.

Также многие не понимают разницу между требованием, потребностью, целью, задачей, договоренностью, рабочим продуктом, результатом работы, результатом сотрудничества и метрикой. Чтобы создать такие документы существуют “методы описаний” или языки нотаций. Эти языки нужно в понятном виде изложить в документе - что так и так будет в документе такая вот информация.

Теперь по существу о полезном софте.

- Каждая программа пишется для поддержки деятельности.

- Деятельность - это целевой набор действий которые совершает определенный деятель.

- Совершая свою деятельность человек выполняет коммуникацию с другими участниками деятельности - обменивается информацией (данными) или информобъектами.

- Для логистики, контроля и поддержки таких информобъетов пишутся системы - тут входная точка откуда мы пишем все задания.

- Процесс выявления деятельности очень тяжелый, и часто разваливается на части потому что выявляет беспорядок в деятельности целевого клиента.

- Формулировка очень продолжительна во времени и попытки собрать всю информацию за раз всегда обречены на провал, поэтому нужна распределенная система.

- В процессе разговоров всегда выясняется что значит то или иное слово - это не допустимо, все должно быть в тезаурусе и в онтологии.

- Каждый информационный объект имеет автора, и порождает действия - вся цепочка должна быть записана.

- и еще очень много чего

В результате я могу сказать только одно - для всего этого дела у меня создан продукт под названием "Мьёльнир" о котором можно посмотреть ролики и описания, и записаться на полноценный тест-драйв его функций.

- Фиксация и анализ всех артефактов

- Живое проектирование и прототипирование

- ТЗ и архитектура на каждую задачу

- Полноценный набор документирования - концепция, замыслы, ситуации, требования, рабочие продукты - модули / размещения

- Ценообразование по описанной экономике из коробки

- Ну и многое другое, о чем я хочу поведать в обзорном вебинаре, поэтому кому интересно ставьте в каментах плюс - сейчас сварганю ссылочку где записаться на просмотр и обсуждеине.

UPD: cсылочка на проект - http://mjolnir.pavlyut.com/

UPD2: исправил опечаточки.