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

Александр Павлють

Причиняю добро путем нанесения пользы прямо в лицо.
Подписаться Написать
сегодня в 19:59
Подробная информация
Контактная информация
deppkind apavlyut id10204261380283557
Проекты пользователя
SPLSport
Помогаем тренерам и спортсменам побеждать
splsport.com
Мьёльнир
Система поддержки разрабокти ПО
mjolnir.pavlyut.com
Мастерская Павлютя
Причиняю добро путем нанесения пользы
www.pavlyut.com
Комментарии
1
> Но на самом деле, я проникся большим уважением. Нужно быть очень настойчивым, чётким и ясным в мыслях, не допускать никаких "неопределенностей" чтобы реализовать в "граните кода" подход: "Система Разделения Труда - это полностью осознанная целевая экономически выгодная деятельность, поделенная на операции, которые разделены на действия, они отнормированы, имеют эталонные показатели, замеряемы и информация о ходе каждого действия (по результативным его точкам) фиксируется и находится в информационной системе поддерживающей эту деятельность."

Так все и есть, благодарю за респект.


> Но я не верю в возможность абсолютного следования этому.

Слово "вера" и "абсолюнного" встречаются в определенной литературе, как привало ничего не имеющей к конкретике. Увы проектировать надо, мактеты делать надо, утвреждать их надо, все это делать надо. Релизы офомлять надо. Фиксы оформлять надо. Цели ставить надо. Прогресс оценивать надо. Результаты измерять надо. Я это заставляю делать. Вы можете этому не следовать. В этом моя гарантия результата и его качества. Я делюсь ей с коллегами и призываю работать качественно а не в болоте понятийной картины. Порядок бьет хаос.

> Я подозреваю, что есть даже теоретические обоснования нецелесообразности и невозможности нормирования и измерений всего, бесконечная декомпозиция операций, структур обязательно приведет к издержкам. Вам говорили про такое? Я чего то неправильно говорю? У Вас есть четкие критерии, по которым легко найти предел?

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

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

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

> У Вас в методологии (кажется я уже спрашивал) не очень понятно как вписать "творчество". В сайтостроении уже давно нет творчества? :(

Что такое творчество - если у человека есть задача разместить на экране 5 элементов, в чем ограничено его творчество предложенных варианвто как это сделать лучше?

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

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

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

Это прозрачность и отвественность - после некоторого итерационного взаимодействия люди начинают работать "молча" и "твроить". Процесс идет.

> С другой стороны, а может действительно - зачем оно в сугубо утилитарных сущностях (вебсайтах для бизнеса). С творчеством это к Артемию Лебедеву ?

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

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


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

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

=)
1 месяц назад
1
> В Питере - тире - ...

дратути

> "Поэтому вы должны “согласовывать” задачи которые нужно исполнять с руководством (заказчиком) на языке понятном заказчику, "
> Пример понятного "языка" - http://files.pavlyut.com/mindactions.v3.0.alpha1.3.png ( Александр, Вам не говорили, что Вы работаете в очень узкой нише и при этом сузили её сами? )

Понятный язык это не равно "укороченый" или "упрощенный" язык для аудитории которая им не владеет.

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

Типичная онотолоческая картина клиента который не понимает в принципе ничего что там за экраном - это все "сайт".

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

И как-то нужно вести коммуникацию внутри команды по каждому из этих понятий.

Ну и давайте конкретно - что на схеме вы считаете нужно убрать и почему. Аргументируйте.
1 месяц назад
1
Коллега, для этого есть порядковый план как это делать и написан он на этой схеме http://files.pavlyut.com/mindactions.v3.0.alpha1.3.png по шагам все заполняем, для этого есть формы.

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

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

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

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

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

Еще есть детали расчетов - но обо всем же в обзорном ролике. Во что кто упрется это не имеет значения - если клиент не хочет работать он не работает и не тратит твое время.
1 месяц назад
1
Коротко, зачаток этого принципа изложен и утвержден тут в 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 (точек зрения) на проект, у меня он называется производство.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ожидайте письмо - в ближайшие недели я разберусь со всеми вопросами и мы сделаем выпуск подробный с обзором и ответом на все вопросы.
1 месяц назад
1
> Сколько у Вас человек в команде?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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