• План/шаблон создания проектной документации?

    apavlyut
    @apavlyut
    www.pavlyut.ru
    Вигерс - разработка требований к программному обеспечению (есть шаблоны)
    Системное мышление (книга + курс) Левенчука - https://system-school.ru/levenchuk
    Ответ написан
    Комментировать
  • Как написать концепцию web-проекта (стартапа)?

    apavlyut
    @apavlyut
    www.pavlyut.ru
    Почитайте книжку Вигерса - разработка требований к ПО. Там есть шаблоны в конце книги.

    Еще верно отмечают что требования к ПО и требования к бизнесу (стартапу) - это разные вещи.

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

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

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

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

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

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

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

    Ну и вигерса не забудьте.

    Успехов!
    Ответ написан
    1 комментарий
  • Подключение сторонних разработчиков в стартап?

    apavlyut
    @apavlyut
    www.pavlyut.ru
    Микросервисы - многие не в курсе что это не "опимизация технического решения" а оптимизация "управления техническим решением".

    Контроль и управляемость повышается не только на:
    - скорости выкладки
    - безопасности связанности сервисов (один упал - второй работает)
    - скорости (от простоты) разработки и тестирования
    - более точного мониторинга.

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

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

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

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

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

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

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

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

    Решения есть - важно понимать что вы "потяните" сами.

    Если у вас как и говорят "мега идея но вы ничего не можете сами" - вы и не сможете без зависимости от внешних талантов.

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

    Готов ответить детально на каждый вопрос всем желающим в комментариях.
    Ответ написан
    Комментировать
  • Как зарегистрировать брэнд на двоих человек?

    apavlyut
    @apavlyut
    www.pavlyut.ru
    Один должен быть главнее по документам.
    Чем дальше откладываете решение выделить главного - тем тяжелее будут последствия.
    А момент настанет в самый неожиданный час.
    Ответ написан
    8 комментариев
  • Нужно ли описывать содержание сайта в ТЗ для программиста если передаёшь ему макет?

    apavlyut
    @apavlyut
    www.pavlyut.ru
    Да.

    На макете происходят действия, действия касаются элементов и происходит реакция.

    Если вы хотите получить то что вам нужно и требовать результат - это надо изложить.
    Ответ написан
    Комментировать
  • Как правильно самому себе накидать ТЗ и план работ?

    apavlyut
    @apavlyut
    www.pavlyut.ru
    Если есть 30 минут, то можно найти все ответы на вопросы тут https://vc.ru/flood/71014-v-budushchee-deystviteln...

    1. Как ставить цели
    2. Какие ставить цели
    3. Как это структурно описать
    4. Как с этим жить дальше.
    Ответ написан
    Комментировать
  • Какие книги посоветуете для будущего Team Lead'a?

    apavlyut
    @apavlyut
    www.pavlyut.ru
    Почитай вот эту статейку (размером почти с книгу, как и просил), полезного про все что тебя ожидает на пути продуктовой разработки и работы над софтом найдешь много - https://vc.ru/flood/71014-v-budushchee-deystviteln...
    Ответ написан
    Комментировать
  • Куда податься на фрилансе?

    apavlyut
    @apavlyut
    www.pavlyut.ru
    Зачем тебе апворк - иди на freelansim.ru, или если хочешь посражаться с нашими индусами тогда и на fl.ru

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

    Так что работать лучше на своей языковой и культурной базе в данном случае (ты не компания которая расширяет рынки присутствия, и разумеется западный рынок шире, поэтому туда как бы надо идти).

    Открой сайт и бери свои заказы на дошик - там их точно тебе хватит.

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

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

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

    Удачи!
    Ответ написан
    3 комментария
  • Agile. Как делить отдел на команды?

    apavlyut
    @apavlyut
    www.pavlyut.ru
    > Вопрос: как разделить коллектив? По каким критериям делить? Чтобы команды были все равны по силам. Есть ли математические решения/методы задачи???

    Вам надо понять чем вы занимаетесь - "утилизируете людские ресурсы" (занимаете работой чтобы не простаивали) либо делаете результат.

    Если второе - команды деляться всегда по продукту работ, которые они производят. В разработке ПО явные продукты это:
    1. результаты аналитики задач
    2. архитектура решения,
    3. проектировка изделий,
    4. оформление изделей
    5. изготовление по платформам / ios / android / web,
    6. тестирование
    7. доставка в эксплуатацию
    8. документирование


    Вокруг таки результатов вы организуете работы.

    Схема моего разделения труда по продуктам работ:

    webp

    Эта схема лежит в основе моего продукта.

    Пример цепочки разделения работ из "Мьёльнира":

    cc6d89fc-e227-4f78-c69b-051646113af1
    Ответ написан
    Комментировать
  • В каком софте можно описать как течение проекта, так и распределение задач?

    apavlyut
    @apavlyut
    www.pavlyut.ru
    В моем проекте, поддерживает полный цикл всей разработки от замысла до ввода в эксплуатацию https://vc.ru/tribuna/67821-melnir-platforma-dlya-...
    Ответ написан
    Комментировать
  • Как поддерживать требования к проекту всегда в актуальном состоянии? Инструменты?

    apavlyut
    @apavlyut
    www.pavlyut.ru
    > Как поддерживать требования к проекту всегда в актуальном состоянии?

    Добрый день. Блиц ответ - регулярно обновлять информацию )

    > Инструменты?

    Сразу к делу - я создатель такого инструмента. Подробности на трибуне vc.ru ->

    > Вопрос больше для тех кто собаку съел в управлении проектами.

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

    > Суть: есть требования к проекту, сначала в виде обзорного ТЗ, потом в виде задачек в трекере, они постепенно реализуются в разрабатываемой системе (ПО), появляются новые, что-то меняется, что-то заказчик передумывает (часть задач теряют актуальность), и т.д.

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

    > И потом бац - а цельной-то картины и нету, приходит например новый разработчик на проект или даже новый менеджер, начинает потом у народа спрашивать, а как вообще надо чтобы работало ? Тестировщик приходит - "меня прислали потестировать, а скажи как оно вообще должно работать ?".

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

    Также эффект в игре-стратегии такой же, я называю его "эффект фонарика" - куда "светите" там и все вам видно, а вот в другом углу куда не светите (нет фокуса) уже не видно.

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

    > Ребята, кто какие системы применяет для управления требованиями к ПО, что вы там храните? - задачи, или UserStories? Куда ткнуться почитать как это вообще по-уму реализовать ?

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

    Короткий ответ в группе уже дал на разницу Jira / Тимсити / Трелы и прочее:

    // цитата

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

    Практики Мьельнира не совсем понятные с ходу - но следуя им вы просто работаете как бы и работали в других системах, но весь контекст будет просто накапливаться и вам никогда не надо будет кому-то "передавть" знания и терять контекст при смене сотрудников.

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

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

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

    // конец цитаты

    > Я не ПМ, знаю что нужно пинать ПМа, но реально пока не понимаю, он что, должен это тупо вручную отслеживать, и документацию в вики или в гугл-доке?

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

    > Всем заранее спасибо.

    Надеюсь не забанят - вроде бы прямой ответ на вопрос.
    Ответ написан
    Комментировать
  • Бизнес план и фин модель для стартапа?

    apavlyut
    @apavlyut
    www.pavlyut.ru
    > Сделал вывод что инвесторам нужны цифры, расчеты, доходы, убытки и прочее. Сколько они вложат и когда они получат n-ую сумму. И так нужен бизнес-план и фин модель. Тут есть человек один, профессионал и просит за глубокий бизнес-план и фин модель 70 000 рублей. Как вы считаете не дорого ли? Но скажу сразу, я уверен в проекте, вопрос лишь времени и хорошего бюджета на рекламу.

    Инвестору не нужны интерфейсы и структура продукта.

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

    Вставлю кусок и своего материала на эту тему на vc:

    /// начало цитаты из статьи

    Дорожная карта

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

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

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

    Цель нельзя "выполнить", можно только "получить".


    • Написать пост - задача. Получить просмотры - цель.
    • Сделать фичу - задача. Получить пользование ей - цель.
    • Открыть бизнес - задача. Получить прибыль в бизнес - цель.
    • Хорошая стратегия (а план это стратегия) - имеет в себе большое количество планов Б. .


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

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

    Хороший план - тот что отвечает на вопрос "а че *ля если нет?"


    Чеклист хорошей дорожной карты / стратегии / плана:

    1. Все задачи приводят к целям.
    2. У ключевых целей отражены планы Б
    3. Логические связи расставлены так, что сразу отпадают вопросы, потому что все "очевидно"
    4. В связи с этим ваши действия становятся простыми:


    Изложить из все что есть в голове о проекте сразу на карту
    1. Расставить связь - причина-следствие
    2. Добавить вариантов развития событий (а что делать если не достиг цели)
    3. Разделить что цель а что задача
    4. Переслать товарищу / инвестору / команде
    5. ...
    6. Profit!


    /// конец цитаты из статьи
    Ответ написан
    5 комментариев
  • Тестирование продукта на фрилансе?

    apavlyut
    @apavlyut
    www.pavlyut.ru
    Да надо.

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

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

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

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

    То есть вы не имеете возможностей (ровно как и любой человек в этом мире) предвидеть все возможные варианты.

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

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

    Разумеется каждый набор тестов с оговоркой на каких девайсах проверяете.

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

    Телепаты же в отпуске.

    Успехов.
    Ответ написан
    4 комментария
  • Как сотрудничать с постоянными клиентами?

    apavlyut
    @apavlyut
    www.pavlyut.ru
    У меня есть ценообразование которое работает так как вы описали, и клиенты за это платят.

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

    UPD: Подробно об этом я рассказал на спарке https://spark.ru/startup/mjolnir/blog/32675/pravil...
    Ответ написан
    4 комментария
  • Алгоритм бесконечной прокрутки контента?

    apavlyut
    @apavlyut
    www.pavlyut.ru
    Правильно гуглить - endless page
    Ответ написан
    Комментировать
  • В какой ИТ-сфере реально продолжить карьеру после 55 лет?

    apavlyut
    @apavlyut
    www.pavlyut.ru
    Научитесь решать проблемы без акцента на технологию - рекомендую изучить тематику по Системной инженерии.
    В этом направлении вы всегда останетесь при любимом техническом инструменте (сами выбираете что необходимо) и будете решать задачи, контролируя и аргументируя техническую часть самостоятельно. Хороших технических директоров крайне мало, платят хорошо, и возьмут именно тех кто "решает" вопросы, путем успешного применения конкретных технологий и направляя персонал на решения которые бизнес крайне ценит.

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

    Успехов.
    Ответ написан
    7 комментариев
  • Стоит тратить свое личное время стартующему фрилансеру на клиента?

    apavlyut
    @apavlyut
    www.pavlyut.ru
    Все что ты делаешь для каждого заказчика обдумай в общую концепцию и сделай сначала твой план работ с клиентами и выложи это на одной странице.

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

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

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

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

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

    Продолжай, и не делай всем раскладки просто так. Успехов.
    Ответ написан
    Комментировать
  • Сервер не принимает PATCH запрос, какие могут быть причины?

    apavlyut
    @apavlyut
    www.pavlyut.ru
    Итого ваше решение после дебага в нашей дискуссии:

    endpoints.cors.allowed-methods=GET,POST,PUT,DELETE,OPTIONS
    Ответ написан
    Комментировать