👍

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

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

Да, в отпуске это вообще омерзительно

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

В итоге, не иметь базу знаний это как минимум аморально )))

Решение было простое: описываем сценарии, согласовываем скетчи.

Просто дисциплинарное соглашение.

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

Золотые слова, в рамочку и на стеночку!

На этой неделе я веду коллективный твиттер руководителей разработки, подписывайтесь, кому интересно, пообщаемся https://twitter.com/leadunderhood

Коллеги! А поделитесь Должностной Иструкцией формальной (прикладываемой к штатному расписанию) для сисадмина (который за серверами следит, а не за локалкой) в личку, plz: @r2d2_e2e4

Мне обрамление и формальная часть не нужны. Только перечень требований к знаниями, обязанности общие без специфики конторы.

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

Заранее спасибо 🙏

SRE, имеете ввиду?
"сисадмин, который следит за серверами" в 2019 жестоко звучит :)

Да, можно и sre

Дмитрию пришлось в тему, а, значит, 'let's share'
Вариант регламента, который писал в 2013 году.

В своё время писал для команды вот такой регламент

Очень удобный документ! 👍

SRE — service reliability engineer, не server

мм.. я отвечу седьмым шаблоном из https://web.devopstopologies.com/