Не буду распостраняться об успехах. Для раздумий есть такая инфа, не сочтите за рекламу: в голд статусе получал до 5 симпатий в день, в не голд статусе получал пару симпатий в месяц.
А как быть, когда ваш продукт развивается на глазах и когда новые фичи становятся базовыми сервисами в течение одного-двух дней, ждать митинга с писателем?
Пилили стартап в таком стиле, вроде никаких проблем замечено не было.
Такая модель хорошо работает, когда у вас идеально отработан процесс постановки задач писателям, а если нет?
Не очень понимаю словосочетания "процесс постановки задач писателям", какие задачи им требуется ставить?
Наш подход работает хорошо отчасти потому что на 1 команду 1 писатель. Как организовать работу одному писателю для 2 и более команд - вопрос хороший. Из предположений - проводить митинги не в одно время, чтоб писатель мог присутствовать на всех.
А что, собственно, мешает переместить бегущего позади писателя на остриё разработки?
Поясню, из личного опыта. Вот обсуждаем с командой новый функционал, вместе с нами сидит писатель и записывает обсуждение. Если у него возникают какие-то вопросы - он может их задать. Далее пишется документация, параллельно создаются эпики, таски и т.д. И разработчики создают тот функционал, который описан в wiki, не больше не меньше. Фактически краткое описание фич в задачах, развёрнутое в wiki и если возникают нестыковки, то люди обращаются к wiki, а потом смотрят в код. Оговорюсь, что наш писатель находится в контексте продукта.
Таким образом в wiki всегда актуальная и наиболее полная информация.
Для вики полно хороших инструментов confluence, gitlab wiki, etc. Которые имею page history. В readme.md описывается узкая информация по конкретному приложению.
Зарабатывая много перед тобой открывается весь мир, велик соблазн не вкладывать в мёртвый камень честно заработанные. Вместо этого можно: вложиться в свои хобби (например, получить права гражданского пилота - будь добр ляма 2-3 заплати), поездить по миру, вложиться в крупные компании, вложиться в рисковые стартапы и т.д. В мире столько всего и это столь много стоит.
Вы не забывайте, что оригинал датируется 2011 годом. Я не говорю, что они потеряли актуальность, но тогда это было не так распространено как сейчас, если было вообще и соответственно автор об этом не говорит. Ну и не забывайте, посыл автора был в том что он «учится».
Вы же знаете про синдром самозванца?
У меня что-то подобное было когда я прыгнул с 40к до 120к за 1 смену работы, при этом задачи не изменились практически.
Пилили стартап в таком стиле, вроде никаких проблем замечено не было.
Не очень понимаю словосочетания "процесс постановки задач писателям", какие задачи им требуется ставить?
Наш подход работает хорошо отчасти потому что на 1 команду 1 писатель. Как организовать работу одному писателю для 2 и более команд - вопрос хороший. Из предположений - проводить митинги не в одно время, чтоб писатель мог присутствовать на всех.
А что, собственно, мешает переместить бегущего позади писателя на остриё разработки?
Поясню, из личного опыта. Вот обсуждаем с командой новый функционал, вместе с нами сидит писатель и записывает обсуждение. Если у него возникают какие-то вопросы - он может их задать. Далее пишется документация, параллельно создаются эпики, таски и т.д. И разработчики создают тот функционал, который описан в wiki, не больше не меньше. Фактически краткое описание фич в задачах, развёрнутое в wiki и если возникают нестыковки, то люди обращаются к wiki, а потом смотрят в код. Оговорюсь, что наш писатель находится в контексте продукта.
Таким образом в wiki всегда актуальная и наиболее полная информация.
Для вики полно хороших инструментов confluence, gitlab wiki, etc. Которые имею page history. В readme.md описывается узкая информация по конкретному приложению.
Добавлю в копилку параллельных вселенных.
Зарабатывая много перед тобой открывается весь мир, велик соблазн не вкладывать в мёртвый камень честно заработанные. Вместо этого можно: вложиться в свои хобби (например, получить права гражданского пилота - будь добр ляма 2-3 заплати), поездить по миру, вложиться в крупные компании, вложиться в рисковые стартапы и т.д. В мире столько всего и это столь много стоит.
История изменений. И автоматическая доставка на сервера через пайплайн.
Не нужно использовать if для ретрая на https. Отдельный блок с 80 портом.
Интересный пост, спасибо. А что по недостаткам?
По-моему, по сравнению с 0 частью статья потеряла лаконичность.
Опишите, пожалуйста, в одной из будущих статей всё разнообразие триггеров. Коротко и без подробного вникание в каждый тип.
И почему же?
На dnsflagday.net пишет всё ок.