Главное Свежее Вакансии   Проекты
Рекомендуем
Хотите больше продаж
по всей России?
Подключите красивый номер 8-800 за 1 рубль
Перейти
Продвинуть свой проект
Выбор редакции:
Как продавать b2b через Facebook: потратили 13 тыс. руб., получили 3 млн руб

Зачем нужны брошенные домены

Spark рекомендует: 9 телеграм-каналов для создателей контента

Меньше букв: подборка сервисов для создания инфографики

Как правильно писать «Вы» или «вы» в деловой переписке?

Тренды маркетинга 2019: что можно добавить в стратегию?

Что нам мешает креативно излагать свои мысли?

Лояка: проверяем гипотезу MVP

Информационные партнеры: как бесплатно продвинуть конференцию по маркетингу и продажам

Как адвокат создала сервис для привлечения инвестиций в судебные процессы

613 11 В избр. Сохранено
Авторизуйтесь
Вход с паролем

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

Всем привет, я Александр, занимаюсь разработкой и созданием систем долго и упорно, у меня к вам серьезный разговор про деньги и вашу экономику.

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

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: исправил опечаточки.

+2
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Выбор редакции:
Как продавать b2b через Facebook: потратили 13 тыс. руб., получили 3 млн руб

Зачем нужны брошенные домены

Spark рекомендует: 9 телеграм-каналов для создателей контента

Комментарии
Первые Новые Популярные
web-агентство ReConcept
ЭКСПЕРТНО РАЗРАБАТЫВАЕМ ЭФФЕКТНЫЕ КОРПОРАТИВНЫЕ САЙТЫ
Сергей Веснин
То, что "чукча - не писатель" - в точку)))
Идея здравая.
Ответить
Мьёльнир
Севрис для поддержки системы разделения труда
Александр Павлють
Спасибо, готов скрестить идею с реальностью на обсуждении - если есть чем надавить на конкретные проблемные места, буду рад на них ответить.
Ответить
web-агентство ReConcept
ЭКСПЕРТНО РАЗРАБАТЫВАЕМ ЭФФЕКТНЫЕ КОРПОРАТИВНЫЕ САЙТЫ
Сергей Веснин
В вашей статье проблема обрисована предельно четко. Это наша боль.
Ответить
DEVOPS OUR CING
H.H. and In P. Запуск в работу IT-проектов
Игорь
Сколько у Вас человек в команде? Сколько PM-ов?... Ничего про тестирование не увидел. С одной стороны - это может быть тривиальная составляющая, а с другой... столкнулся я как то раз, что заказчик на себя взял тестирование (пересчет на реальных данных в новом инструменте и сравнение с расчетами на старом) :) :) :). Это я сейчас улыбаюсь, а тогда этот "тривиальный этап" занял в три раза больше времени чем разработка, половина из этого времени было потрачено на терки, что подразумевалось под словосочетанием "тестирование функционала на реальных данных - в зоне ответственности заказчика".
Ответить
Мьёльнир
Севрис для поддержки системы разделения труда
Александр Павлють
> Сколько у Вас человек в команде?

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

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

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

> Сколько PM-ов?...

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

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

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

По сути я не говорил внятно про тестирование, но в общем изложении тестирование я представил так, еще раз тут обобщу:

1. Когда задача идет в работу она имеет подробную поэлементную смету (компоненты + состояния / то что называют иногда раскадровкой) и она идет в работу, подразумевается что клиент это видит и до момента старта работ он может на это повилять.

2. Когда задача пошла в изготовление - результатом программиста должна быть работающая задача согласно заданию. То есть если она не работает, она не выполнена.

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

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

Также в проекте задачи четко фиксируются структуры данных которые будут задействованы.

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

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

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

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

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

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

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

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

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

Я это все наэксперементировал уже вдоль и поперек - это работающие конструкции которые действительно упрощают всем участникам проекта жизнь. Если вам интересно, то новый обзор будет содержать этот функционал конкретно про тесты, записывайтесь там в шортлист я линк всем отправлю как подготовлюсь к демке.
Ответить
DEVOPS OUR CING
H.H. and In P. Запуск в работу IT-проектов
Игорь
Записался в шорт, что то ничего пока не пришло :(

Смотрел предыдущее видео. Сразу вопрос возник - где ВЫ находите клиентов, которые через такой инструмент сами контролируют "как у нас дела". Получается, у Вас PM-нет, потому что эта роль переложена на заказчика. И здесь четкое ценообразование конечно же играет важную роль. Типа, это не мы такие "дорогие и с потолка цены берем" - это система бездушная :) всё считает. Как в команде инструмент воспринимается? Много ли творческих личностей, которые протестуют против "формализьма и подробного протоколирования каждого шага" Знаю по опыту работы с проектами в битриксе (кстати, почему то он сразу и вспоминается при просмотре Вашего инструмента, и вспоминается, что иногда мощный функционал - это недостаток, потому что его мощь надо освоить и поддерживать). Про эксплуатацию вопрос, у Вас есть четкое разделение по специалистам, это админы-эксплуатационщики, это веб-программисты, или у Вас уровень железа и скулей, виртуалок - это на подряде у хостеров ?
Ответить
Мьёльнир
Севрис для поддержки системы разделения труда
Александр Павлють
> Записался в шорт, что то ничего пока не пришло :(

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

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

> Смотрел предыдущее видео. Сразу вопрос возник - где ВЫ находите клиентов, которые через такой инструмент сами контролируют "как у нас дела".

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

> Получается, у Вас PM-нет, потому что эта роль переложена на заказчика.

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

> И здесь четкое ценообразование конечно же играет важную роль. Типа, это не мы такие "дорогие и с потолка цены берем" - это система бездушная :) всё считает.

Есть очень архитектурная схема + кликабельный прототип + развертка всех компонентов по состояниям + детальная опись элементов. С учетом сложности фибоначчи выводится смета. Длиииная такая херь с точной ценой снизу и порядком учета сумм. Ноль вопросов на приемке - НОЛЬ. На что деньги, куда деньги и тд - не буду сейчас расписывать, я решил полностью проблему приемки передачи и правок, переработок и недоплат. Работа просто идет, фичи по жизненному циклу крутятся - лавеха мутится.

Длинная смена + на эту смету есть понятный договор который проходит любой юр отдел и бухгалтерию.

Об этом обзор готовится большой.

> Как в команде инструмент воспринимается? Много ли творческих личностей, которые протестуют против "формализьма и подробного протоколирования каждого шага"

Хороший вопрос - эта система разделения труда дает четкое разленеие на "пседотворцов" которые прикрываются бардаком и хаосом чтобы окружающие не знали какой он на самом деле "чиновник" - занял место и курирует коммуникацию вокруг своего "места" заболочивая ее, тем самым усложняя спрос с себя и своей работы. Внедрял все это в СПБ летом, остались следы проекта - там как раз разбежались такие вплоть до внутреннего переворота в компании, в итоге мне в открытую призналось руководство компании где я это все внедрил - им надо чтобы все сидели по своим местам и никто никого не беспокоил. Это проигрышная позиция, люди так сами устраивают себе колхоз.

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

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

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

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

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

Тут даже сравнивать сложно - все со всем связано, а у битрикса другие задачи и они не связаны с тем чтобы вы делали нужные результаты у себя. Это разные миры для них.

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

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

> Про эксплуатацию вопрос, у Вас есть четкое разделение по специалистам, это админы-эксплуатационщики, это веб-программисты, или у Вас уровень железа и скулей, виртуалок - это на подряде у хостеров ?

Я утвреждаю что разработчик это тот кто может свой продукт довести до стадии эксплуатации. Поэтому вопрос девопса тут закрывается сразу. Разумеется это в простых случаях облака типа heroku (основной стек), в более сложных играх это "свой хероку" собранный на ansible и capistrano затестированный деплоймент, но движуха там идет в контейнерах и в последнее время я не вижу смысла работать вне heroku в принципе. Об этом отдельно можно говорить, но у меня и на это есть архитекутрное проектирование с подкреплением. Эффективность экслпуатации в экономическом расчете задает тон. Многие сидят считают стоимости hetzner и ноют на тарифы амазона или того же heroku, это как правило те кто не оплачивал из своего кармана и не пытался проконтролировать и как-то "загарантировать" себе стабильность инфарстуктуры.

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

Ожидайте письмо - в ближайшие недели я разберусь со всеми вопросами и мы сделаем выпуск подробный с обзором и ответом на все вопросы.
Ответить
DEVOPS OUR CING
H.H. and In P. Запуск в работу IT-проектов
Игорь
!!! Спасибо за подробный ответ, но вопросы остаются :) Я понимаю, что всё уже давно придумано и все сайты состоят из стандартных элементов, но как тарифицируется "исследовательская" работа? Или такой не осталось, или чисто по количеству итераций приближений к согласию клиента "годно" ?.... Простой пример, во сколько бы Ваш инструмент оценил исправить дизайн комментариев на Спарке? Когда узкий столбик длинной портянки занимает всего одну пятую по ширине пустого практически пространства?
Ответить
Мьёльнир
Севрис для поддержки системы разделения труда
Александр Павлють
Коротко, зачаток этого принципа изложен и утвержден тут в 2016 году http://www.pavlyut.com/pricing. Система просто "догоняет" его и облегчает труд, так как но фактически работа поэтому принципу у меня уже давно идет (лет пять точно) в плане оценки стоимостей, просто клиентам не доступны были эти рассуждения.

Со временем все обрело форму, трассировалось нормально, выявились все эти детали и вот года два или три уже назад я четко сделал первую попытку загнать это в продукт в котором тоже отработал какое-то время, опять же тут "пробовал" его на обратную связь от мира - https://spark.ru/startup/mjolnir/blog/24054/o-proekte-artefactor

И сама тогдашняя версия продукта http://www.pavlyut.com/cases/artefactor.

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

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

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

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

Именно на такое демо я и рассчитываю - рил ток чтобы был, отработать реальную ситуацию которая покажет как все прекрасно управляется.
Ответить
DEVOPS OUR CING
H.H. and In P. Запуск в работу IT-проектов
Игорь
Ага :) мне кажется этот рил ток на первом же моменте упрется в то, что "как надо" - заказчик может понимать очень смутно. И будет не-прочь забесплатно эти муки выбора разделить с разрабом.
Ну вот например: Типа я от Спарка: А мне вот не нравится, что на ноутбуке и на широком экране - поле с комментами совсем не "элластичное" и такое узкое-узкое... возможно потому, что прошлый разраб это заточил под смартфоны, но мне - не нравится, хочу чтобы как в хабрахабре, а лучше ещё красивше и удобнее :) Сколько будет стоить ?
Ответить
Мьёльнир
Севрис для поддержки системы разделения труда
Александр Павлють
Коллега, для этого есть порядковый план как это делать и написан он на этой схеме http://files.pavlyut.com/mindactions.v3.0.alpha1.3.png по шагам все заполняем, для этого есть формы.

А вот сколько будет стоить указывается в реализации всего предложения в примере сметы - http://files.pavlyut.com/mjolnir-offer-sample.png

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

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

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

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

Еще есть детали расчетов - но обо всем же в обзорном ролике. Во что кто упрется это не имеет значения - если клиент не хочет работать он не работает и не тратит твое время.
Ответить
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать