Co-Author 1/3: Why?
Один из навыков, которому Меня научила книга Валеры и Арсения, – это "видеть лес за деревьями": смотреть на систему целиком (в контексте, а не в вакууме); думать о дизайне системы (и это касается не только ML-сервисов); да и вообще, документировать дизайн систем, с которыми работаешь или которые строишь. В частности, перенос этих знаний так или иначе происходит на менеджмент.
Я развиваю Симулятор ML почти 2.5 года, за это время мы с командой младших авторов (@avalexey @unipply0 @redpf) и project-менеджерами успели перестроить процессы несколько раз, попробовать много разного и прийти к некому более-менее устоявшемуся флоу, которого придерживаемся по сей день, и который продолжаем совершенствовать. Об одном недавнем кардинальном улучшении Я не могу умолчать...
Значит, решили мы в августе систематизировать весь процесс разработки контента от идеи до релиза. Мы написали Мастер-Документ на 7000 слов, который содержит, например:
• Какими принципами мы руководствуемся при написании задач? Каким мы дизайним опыт (UX) для студента?
• По каким метрикам мы определяем качество продукта? – у нас есть целая иерархия метрик от верхнеуровневых денег / костов – до числа багов, разнообразия по доменам и проектам, проходимости, качества текста / картинок / числа отсылок задач друг к другам (к слову, конкретно к этому подтолкнула глава книги "Loss functions and metrics");
• Какая анатомия задач? Какие подвиды задач? – чтобы вы понимали, задачи состоят из истории (мы в таком-то продукте, вот такая проблема, сходи туда, выгрузи то, подумай какую модель применить здесь), теории (и ссылок), требований к решению, решения и самой проверяющей системы, и наконец, картинок в нашем уникальном стиле;
• Как формируем и приоритезируем беклог спринта? Где берём идеи для новых задач? (часть предлагают студенты в нашем Upvoty, часть придумываем мы);
• Какой у нас Definition-of-Done? Как/когда мы релизим? Что делаем после? Где собираем баги?
...и многое другое.
P.S. В комментариях делюсь парой лайфхаков.
#management
Один из навыков, которому Меня научила книга Валеры и Арсения, – это "видеть лес за деревьями": смотреть на систему целиком (в контексте, а не в вакууме); думать о дизайне системы (и это касается не только ML-сервисов); да и вообще, документировать дизайн систем, с которыми работаешь или которые строишь. В частности, перенос этих знаний так или иначе происходит на менеджмент.
Я развиваю Симулятор ML почти 2.5 года, за это время мы с командой младших авторов (@avalexey @unipply0 @redpf) и project-менеджерами успели перестроить процессы несколько раз, попробовать много разного и прийти к некому более-менее устоявшемуся флоу, которого придерживаемся по сей день, и который продолжаем совершенствовать. Об одном недавнем кардинальном улучшении Я не могу умолчать...
Значит, решили мы в августе систематизировать весь процесс разработки контента от идеи до релиза. Мы написали Мастер-Документ на 7000 слов, который содержит, например:
• Какими принципами мы руководствуемся при написании задач? Каким мы дизайним опыт (UX) для студента?
• По каким метрикам мы определяем качество продукта? – у нас есть целая иерархия метрик от верхнеуровневых денег / костов – до числа багов, разнообразия по доменам и проектам, проходимости, качества текста / картинок / числа отсылок задач друг к другам (к слову, конкретно к этому подтолкнула глава книги "Loss functions and metrics");
• Какая анатомия задач? Какие подвиды задач? – чтобы вы понимали, задачи состоят из истории (мы в таком-то продукте, вот такая проблема, сходи туда, выгрузи то, подумай какую модель применить здесь), теории (и ссылок), требований к решению, решения и самой проверяющей системы, и наконец, картинок в нашем уникальном стиле;
• Как формируем и приоритезируем беклог спринта? Где берём идеи для новых задач? (часть предлагают студенты в нашем Upvoty, часть придумываем мы);
• Какой у нас Definition-of-Done? Как/когда мы релизим? Что делаем после? Где собираем баги?
...и многое другое.
P.S. В комментариях делюсь парой лайфхаков.
#management