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

Но вместо этого есть опус на тему страданий недоменеджера в аду кривых процессов.

Это лучшая статья в поддержку ремоута, ведь теперь можно кидаться в любого приверженца офиса этим, типа «ну да, если процессы выстроить не можешь — обвиняй во всем удаленку»

Вот правда, я все ещё считаю, что в офисе люди(большинство) работают продуктивнее. Но вы правда считаете, что в описаном именно удаленка корень всех бед?
Менеджер, которому скучно слушать разработчика, и который не умеет планировать время. И который «по-работать» считает время потраченное на презентацию.
Команда, которая не может договорится про мессенджеры.
Поздние созвоны (да, тут тоже виновата удаленка)

Собственно, где про проблемы создания рабочей атмосферы то? В чем експеремент заключается? Что пришлось изучать? Что «впроваджувати в мегашвидкому темпі»? От чего отказываться? От чего усталость то хоть накапливается?

Практика работает во благо, если
— «скидывание» абсолютно добровольное, если кто не скинулся — это не превращается в травлю да и вообще не афишируется
— Есть человек (HR/манагер) который следит за ВСЕМИ др. Это супер важно, никто не должен быть забыт
— маленький коллектив. 10 человек — уже много.
— Коллектив УЖЕ достаточно дружен, о сотрудниках знают достаточно, чтоб выбрать хороший подарок. Подарок деньгами — символ каргокульта (кроме ситуаций, когда известно, что у сотрудника проблемы с деньгами и ему так нужнее).

Другими словами, во благо, это когда подарки/посиделки — это проявление, следствие хорошей атмосферы в коллективе. Если пытаться устроить каргокульт типа «в хороших коллективах так принято» — то лучше не станет.

В скраме — нет. Впрочем, тут моя ошибка, — скрам это и не методология разработки.

Нет, скрам это что-то типа «Основы построения баз данных». А уже какие паттерны вы будете использовать в ходе реализации конкретной базы данных — это уже будут design patterns. Хотя как раз скрам очень жестко ограничивает набор возможных методов.

Короче — другой уровень абстракции.

Это очень странный вопрос.
en.wikipedia.org/wiki/Methodology
Грубо говоря, методология — это теоритическая база, которая позволяет выбрать необходимый метод решения.

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

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

Кстати, за книжку спасибо.

Меня радует ваш уровень общения :).
Я смотрел ваш линк, и меня удивило, что вы решили что это «книжка с паттернами методологий». Забавно, что в самой «книжке с паттернами методологий» слово «методология» (methodology) встречается 13 раз (в контексте отсылок к методологиям, откуда взяты паттерны).

Для сравнения, слово «шаблон» (pattern) встречается в тексте порядка 1500+ раз. Что не удивительно — книжка то про шаблоны, а не про методологию.

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

Ох блин, а зачем вы слово «методология» туда притащили?
Design Patterns: Elements of Reusable Object-Oriented Software — это методология разработки, получается? Или конструктор методологий? :)

Можете расшифровать чуть больше? А то вашу фразу можно истолковать и как
«Можно менять время итерации», и как «Вот дейли митинг мы взяли, остальное — нет, но у нас все равно скрам»

Смотрите. Вот как выглядит методология: en.wikipedia.org/...​agement_Body_of_Knowledge (~600 страниц)

Методология — это не «у нас изначально было толковое ТЗ и поэтому мы не пытались из носорога сделать аиста». Методология — это довольно детальное описание процессов, практик, артефактов, исполнение которых позволяет значительно повысить ваши шансы на успех.

Ничего подобного для «водопада» нет. Ну потому, что это не методология. Это была просто модель, которую придумали, чтоб показать, что так оно не работает.

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

ох, и правда какой?
Только вы это, поосторожнее с аналогиями, а то договоримся, что «аджайл» изобрели в 3-ем тысячелетии до н.э. ru.wikipedia.org/wiki/Ломаная_пирамида

А уж как в Киеве дома строятся — так это чистая итеративная разработка: сначала получаем документы на офисное здание, начинаем строить, в процессе перекидываем назначение земли, получаем доки на жилое малоэтажное здание, потом доращиваем этажи и пытаемся узаконить.

P.S. шутки-шутками, но мешать «производство» и «разработку» — это уже за гранью

Если вы хотите получить консультацию — это в личных сообщениях :)

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

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

Извините, я не понимаю вас. Можете дать прямой ответ: QA/QC — это от недоверия или все же необходимый процесс?

Интересная мысль. Я правильно понимаю, что QA/QC процессы, код ревью, логи ошибок, трекинг действий пользователей — это все тоже от недоверия? И у «правильного» руководителя их нет, т.к. он свято верит всем сотрудникам, а сотрудники — биороботы и не ошибаются.

Если вы пускаете написание документации на самотек (надеетесь, что нужные люди в нужный момент по своей инициативе внесут информацию в вики, или куда там вы ее вносите) — то да, вы абсолютно правы

Есть 2 вопроса.
Первый — процессуальный. QA — подтверждает сроки, Разраб — планирует релизы и сроки разработки. Ок, допустим, что это даже реально. Но если не попадем в сроки — кто несет ответственность? QA плохо подтвердили или разработчики фигово релиз спланировали?

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

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

Severyn Rybchynskyy вы не могли бы после «дейли-синкапа» взять произвольного сотрудника и попросить его рассказать про всех остальных членов команды: что они вчера делали, с какими проблемами столкнулись, что сегодня будут делать и какие блокеры.

Никакой другой менеджмент в нём не задействован, и зачастую вообще не в курсе, что происходит на самом деле.

Извини, но такому стартапу кирдык.

A chief technology officer (CTO), sometimes known as a chief technical officer or chief technologist, is an executive-level position in a company or other entity whose occupation is focused on the scientific and technological issues within an organization.[1] en.wikipedia.org/...​/Chief_technology_officer

И как называется та роль, которую ты описал?