Forwarded from tropical saint petersburg
шок-контент— сравнение математического образования на МКН и в MIT не в пользу последнего.
разная философия образования, и устройство общества. В хороших местах в России вас сразу много и интенсивно учат, бакалаврские спецкурсы сравнимы с аспирантскими в Штатах. Поэтому в аспирантуре вас нечему учить (и обычно нет аспирантских курсов). Казалось бы, занимайся наукой в нехочу.
но для этого нужны крутые научные руководители (а среднего возраста учёных в России мало, провал) и вообще привлекательность научной карьеры тоже так себе. Получается гипертрофированная первая ступень — в толпу умных людей вбивают много знаний, которые потом не нужны.
условная "либеральная западная модель" гораздо менее интенсивна на первых этапах (с "нестрогими идеями" вместо доказательств в бакалавриате, например) и серьёзное обучение начинается в аспирантуре. Зато к этому моменту отсеялись те, кому неинтересно, и кто не хочет сам разбираться в материале, и в топовых местах много крутых учёных для научного руководства (+ многие аспиранты приезжают в топовые места из нетоповых).
это не лучше и не хуже, просто другая модель (для поддержания которой, например, кажется важным большой приток умных иностранцев аспирантов), с другими акцентами. Ну а для науки (как мне кажется) важно не то, как учат, а концентрация очень сильных учёных в одном пространстве.
так что хорошо, что цветут все цветы.
разная философия образования, и устройство общества. В хороших местах в России вас сразу много и интенсивно учат, бакалаврские спецкурсы сравнимы с аспирантскими в Штатах. Поэтому в аспирантуре вас нечему учить (и обычно нет аспирантских курсов). Казалось бы, занимайся наукой в нехочу.
но для этого нужны крутые научные руководители (а среднего возраста учёных в России мало, провал) и вообще привлекательность научной карьеры тоже так себе. Получается гипертрофированная первая ступень — в толпу умных людей вбивают много знаний, которые потом не нужны.
условная "либеральная западная модель" гораздо менее интенсивна на первых этапах (с "нестрогими идеями" вместо доказательств в бакалавриате, например) и серьёзное обучение начинается в аспирантуре. Зато к этому моменту отсеялись те, кому неинтересно, и кто не хочет сам разбираться в материале, и в топовых местах много крутых учёных для научного руководства (+ многие аспиранты приезжают в топовые места из нетоповых).
это не лучше и не хуже, просто другая модель (для поддержания которой, например, кажется важным большой приток умных иностранцев аспирантов), с другими акцентами. Ну а для науки (как мне кажется) важно не то, как учат, а концентрация очень сильных учёных в одном пространстве.
так что хорошо, что цветут все цветы.
Digital Russia
Миф о классном обучении математике и компьютерным наукам в бакалавриате MIT
Об авторе: Анатолий Шалыто, профессор, д.т.н., Университет ИТМО. На канале «Гарвард-Оксфорд» вышло видео, в котором Данил Сибгатуллин из Казани,
Вчера разбирали с тимлидами главы с седьмой по девятую Брукса. В главе Calling the Shot есть прям данные. Я люблю данные, вы любите данные (основано на данных о похожих на мой каналах), все любят данные (не основано на данных). Данные говорят о нескольких вещах.
1. Чем больше система (просто в количестве инструкций), тем меньше кода в ней производят разработчики. Потому что система сложнее. Причем там нелинейный рост сложности. На данных из книги у Брукса получилось
2. Чем больше коммуникаций между разработчиками (для синхронизации работы), тем меньше кода они пишут.
3. Чем больше коммуникаций (неявно выводим — точек сочленения) между командами, тем меньше кода пишут программисты. Здесь вообще всё драматично: 10к инструкций per man-year при маленьком количестве взаимодействий и 1,5к инструкций per man-year при частых взаимодействиях. На порядок!
4. Есть существенная разница в скорости разработки между командами, работающими над разными классами задач (управляющие программы разрабатывались в пять раз медленнее на программиста, чем, пусть и сложный, продукт: компиляторы и ассемблеры).
5. На языках высокого уровня инструкций в единицу времени пишется в пять раз больше, чем на ассемблере.
6. Половина времени разработчиков уходит НЕ на написание и отладку кода. Митинги, больничные, оформление бумаг, личные дела, срочные важные задачи, УМЕР ВАЙФАЙ, ДАЛЕКО ИДТИ ЗА КОФЕ, РАЗМЯТЬ СПИНУ — подобные вещи отъедают половину рабочего времени.
Мы у себя наблюдаем эти закономерности прямо сейчас. Программисты в инфраструктурных командах пишут меньше кода, чем программисты в продуктовых. Даже если это один и тот же программист (у нас есть люди, перешедшие по ротации из продукта, тот же язык, тот же опыт, те же технологии — кода меньше). Есть и обратные примеры.
Кроме того, новые системы, как наш PSP, разрабатываются быстрее, чем большие старые. А разработка сильно замедляется после ввода системы в эксплуатацию — прорастают коммуникации с другими командами, появляется фон багов и т.д.
Какие выводы можно сделать?
Не знаю. Но как минимум мы видим, что сравнивать разработчиков по объемам кода очень сложно. Ещё мы видим, что не приходится расчитывать на 40 часов в неделю от среднего разработчика.
Вот про последнее есть у Джоела и здесь. В первой статье рассказывается про компании быстрого роста: покупай время за деньги (здесь про зп выше рынка, три бэхи и ассистентов). А во второй про продуктивность сотрудников в зависимости от условий на работе (опенспейсы, кофемашины, хороший рабочий софт и железо).
Вообще статьи не об этом, но моментики важные.
Советов не будет.
1. Чем больше система (просто в количестве инструкций), тем меньше кода в ней производят разработчики. Потому что система сложнее. Причем там нелинейный рост сложности. На данных из книги у Брукса получилось
effort = C * (LOC)^1.5.2. Чем больше коммуникаций между разработчиками (для синхронизации работы), тем меньше кода они пишут.
3. Чем больше коммуникаций (неявно выводим — точек сочленения) между командами, тем меньше кода пишут программисты. Здесь вообще всё драматично: 10к инструкций per man-year при маленьком количестве взаимодействий и 1,5к инструкций per man-year при частых взаимодействиях. На порядок!
4. Есть существенная разница в скорости разработки между командами, работающими над разными классами задач (управляющие программы разрабатывались в пять раз медленнее на программиста, чем, пусть и сложный, продукт: компиляторы и ассемблеры).
5. На языках высокого уровня инструкций в единицу времени пишется в пять раз больше, чем на ассемблере.
6. Половина времени разработчиков уходит НЕ на написание и отладку кода. Митинги, больничные, оформление бумаг, личные дела, срочные важные задачи, УМЕР ВАЙФАЙ, ДАЛЕКО ИДТИ ЗА КОФЕ, РАЗМЯТЬ СПИНУ — подобные вещи отъедают половину рабочего времени.
Мы у себя наблюдаем эти закономерности прямо сейчас. Программисты в инфраструктурных командах пишут меньше кода, чем программисты в продуктовых. Даже если это один и тот же программист (у нас есть люди, перешедшие по ротации из продукта, тот же язык, тот же опыт, те же технологии — кода меньше). Есть и обратные примеры.
Кроме того, новые системы, как наш PSP, разрабатываются быстрее, чем большие старые. А разработка сильно замедляется после ввода системы в эксплуатацию — прорастают коммуникации с другими командами, появляется фон багов и т.д.
Какие выводы можно сделать?
Не знаю. Но как минимум мы видим, что сравнивать разработчиков по объемам кода очень сложно. Ещё мы видим, что не приходится расчитывать на 40 часов в неделю от среднего разработчика.
Вот про последнее есть у Джоела и здесь. В первой статье рассказывается про компании быстрого роста: покупай время за деньги (здесь про зп выше рынка, три бэхи и ассистентов). А во второй про продуктивность сотрудников в зависимости от условий на работе (опенспейсы, кофемашины, хороший рабочий софт и железо).
Вообще статьи не об этом, но моментики важные.
Советов не будет.
Joel on Software
Strategy Letter I: Ben and Jerry’s vs. Amazon
Building a company? You’ve got one very important decision to make, because it affects everything else you do. No matter what else you do, you absolutely must figure out which camp you’…
👍7❤2
Несколько месяцев назад прочитал статью про проектный менеджмент. Там утверждалось, что если в проекте из 20 задач, каждая сходится в срок с вероятностью 90%, то проект целиком сходится в срок с вероятностью *попробуйте угадать*. Ответ, который загадал автор посчитать довольно просто, вы умеете, спрячу под спойлер (12% ).
Но вот только он неверный.
КАРТИНКИ КАРТИНОЧКИ ЩАС БУДУТ!
Во-первых, когда ответ верный?
Только, когда это не проект, а куча независимых задач, все из которых делаются одновременно и параллельно. Тогда, действительно, вероятность, что хотя бы одна задача завалится и мы продолбаем сроки такая, как загадал автор.
Но давайте, все-таки проект возьмем.
Здесь нужно явно проговорить предпосылки.
1. Задачи не параллелятся и идут строго друг за другом
2. Вероятности закрыть задачи в срок не зависят друг от друга
3. Все задачи одинаковой длины
Давайте ещё всё-таки считать, что если с 90% вероятностью задача попадает в дедлайн, то она с некоторой вероятностью может быть сделана и раньше дедлайна. Вопреки "закону Дорофеева", я верю, что так бывает.
Ещё давайте считать не точное попадание проекта в дедлайн (оно очевидно стремится к нулю с ростом размера и количества задач), а вероятность закончить проект _до_ дедлайна включительно.
Я взял задачи размером 100 (давайте считать часов).
Я взял 20 задач в проекте.
Тогда проектный дедлайн это 2000 часов.
И расчехляем Монте-Карло симулятор!
Для простоты можем считать, что распределение вероятностей сделать задачку в первый, второй и т.д. час равномерное. Тогда надо взять распределение на (0, 111], на нем с 90% вероятностью задача займет 100 часов. В среднем проект из 20 задач займёт тогда 1113+-144(1 std) часов. С вероятностью 99% проект займет не более 1457 часов.
Можно посмотреть график. На нем есть черным плотность вероятности и гистограмма одного из реально сгенерированных сэмплов (я делал по 1000 симуляций на каждый проект). Оси не подписал, каюсь. По горизонтали длительность одной задачи, по вертикали вероятность того, что задача займет именно столько времени. И, да, считаем, что среднее сходится к матожиданию здесь, поэтому длительность проекта это сумма длительностей задач.
Но вот только он неверный.
КАРТИНКИ КАРТИНОЧКИ ЩАС БУДУТ!
Во-первых, когда ответ верный?
Только, когда это не проект, а куча независимых задач, все из которых делаются одновременно и параллельно. Тогда, действительно, вероятность, что хотя бы одна задача завалится и мы продолбаем сроки такая, как загадал автор.
Но давайте, все-таки проект возьмем.
Здесь нужно явно проговорить предпосылки.
1. Задачи не параллелятся и идут строго друг за другом
2. Вероятности закрыть задачи в срок не зависят друг от друга
3. Все задачи одинаковой длины
Давайте ещё всё-таки считать, что если с 90% вероятностью задача попадает в дедлайн, то она с некоторой вероятностью может быть сделана и раньше дедлайна. Вопреки "закону Дорофеева", я верю, что так бывает.
Ещё давайте считать не точное попадание проекта в дедлайн (оно очевидно стремится к нулю с ростом размера и количества задач), а вероятность закончить проект _до_ дедлайна включительно.
Я взял задачи размером 100 (давайте считать часов).
Я взял 20 задач в проекте.
Тогда проектный дедлайн это 2000 часов.
И расчехляем Монте-Карло симулятор!
Для простоты можем считать, что распределение вероятностей сделать задачку в первый, второй и т.д. час равномерное. Тогда надо взять распределение на (0, 111], на нем с 90% вероятностью задача займет 100 часов. В среднем проект из 20 задач займёт тогда 1113+-144(1 std) часов. С вероятностью 99% проект займет не более 1457 часов.
Можно посмотреть график. На нем есть черным плотность вероятности и гистограмма одного из реально сгенерированных сэмплов (я делал по 1000 симуляций на каждый проект). Оси не подписал, каюсь. По горизонтали длительность одной задачи, по вертикали вероятность того, что задача займет именно столько времени. И, да, считаем, что среднее сходится к матожиданию здесь, поэтому длительность проекта это сумма длительностей задач.
Но равномерное распределение какое-то неживое. Гораздо более правильным будет взять логнормальное, на мой вкус.
Мне просто кажется, что относительные оценки сроков задач (ну, считай, ошибки в оценке) распределены нормально, а не сами оценки (было бы тупо).
Да и в целом график выглядит убедительно, сами смотрите: макс вероятность закончить реально где-то ближе к сроку, но в теории можно никогда не закончить 🤡
Короч, вот я взял логнормальное распределение.
Например, со стандартным отклонением 30% (графики есть для 10, 30 и 90). В среднем проект тогда будет закрываться за 1420+-100 часов, а 99%% это 1665 часов.
Что меня несколько удивило, так это что при увеличении неопределенности (она симметричная), вероятность закончить в срок только растёт (см. для 0.1 и для 0.9). Контринтуитивно, если честно.
Во всех случаях вероятность закончить проект в срок, если каждая задача придет в срок с вероятностью 90%, сильно больше 99% и уж никак не12% .
Мне просто кажется, что относительные оценки сроков задач (ну, считай, ошибки в оценке) распределены нормально, а не сами оценки (было бы тупо).
Да и в целом график выглядит убедительно, сами смотрите: макс вероятность закончить реально где-то ближе к сроку, но в теории можно никогда не закончить 🤡
Короч, вот я взял логнормальное распределение.
Например, со стандартным отклонением 30% (графики есть для 10, 30 и 90). В среднем проект тогда будет закрываться за 1420+-100 часов, а 99%% это 1665 часов.
Что меня несколько удивило, так это что при увеличении неопределенности (она симметричная), вероятность закончить в срок только растёт (см. для 0.1 и для 0.9). Контринтуитивно, если честно.
Во всех случаях вероятность закончить проект в срок, если каждая задача придет в срок с вероятностью 90%, сильно больше 99% и уж никак не
👍6
Есть две школы мысли: таймбоксинг и скоупбоксинг. Я отношусь ко второй. И сейчас я вам покажу откуда готовилось, почему же задачи иногда всё-таки делаются раньше дедлайна.
Нарисовали мы себе красивого ганта, смотрим на него, любуемся, а он устаревает. Где-то в этом ганте лежит большая вкусная задача на две недели плотненькой разработки. Ведущий программист Василий с предвкушением берёт эту задачу из бэклога и начинает её делать. Через пятьдесят минут после начала Василий понимает, что для завершения этой достаточно вот в этом вот файлике вот эту вот строчечку поправить и заработает по спеке. Через три часа Василий уже открыл пулл-реквест и прошёл все тесты.
В реальной жизни далее возможны два исхода. Василий говорит ПМ'у, что задача была оценена неверно и уже готова, берёт следующую большую вкусную задачу и делает. Либо, по закону Паркинсона, Василий умудряется потратить время до дедлайна по задаче "с пользой". Нам интересно второе.
Василий окинул бэклог беглым взглядом. Больше никаких больших, вкусных задач в этом месяце не предвиделось. Осталась одна фигня, — подумал он, — если уж мы ТАКОЕ за день сделали, то мелочевка проскочит вообще незамеченной. Всё потому, что я крутой специалист, как никак ведущий разработчик. А вот зато эту большую вкусную задачу в таком виде мержить нельзя, просто стыдно! Мидлы засмеют. Надо вот тут выделить класс, здесь функции вынести в отдельный класс, и вообще, как-то плохо этот кусок написан, надо молодым бойскаут рул показать.
Василий садится за небольшой рефакторинг. Время есть, запас большой, может себе позволить. Через четыре часа он замечает, что можно очень круто обобщить вот этот кусок и тогда можно будет закрыть еще и тикет, который висит с позапрошлого года — всё руки не доходили. Но тут что-то тесты покраснели. Надо бы исправить. Ой, а тесты-то какие плохие! Ну кто так делает? Уф, всему надо учить, даже тесты за ними рефачить приходится.
Пока Василий рефачил, делал какие-то крутые, но никому не нужные фичи (в смысле никому не нужна конфигурация размера кеша http-заголовков??), чинил тесты и учил молодежь, как делать пулл-реквесты на 4к LOC, прошло довольно много времени. Возможно, Василий даже умудрился опоздать к дедлайну, потому что опять забыл заложить время на UA-тестирование.
Как же можно этого избежать? Нужно контролировать скоуп! Должна быть написана спека. Спека это просто, человеческим языком объяснение, что должна делать система. Вход, выход, сайд-эффекты. Круто, если будет еще и формальная спека (openapi, матан, jls ch. 17.4, you name it). Но хотя бы словами.
Спека должна быть минималистична в смысле MOVE (Minial Outcome-Value Effor). То есть фича в спеке должна иметь ценность сама по себе (без необходимости делать еще какие-то фичи, можно продавать, как есть), но при этом в ней абсолютный минимум функционала.
Но спеки недостаточно. Нужно жестко следить за тем, чтобы в рамках задачи/фичи не делалось ничего такого, что в задаче не описано. То есть разработчик должен делать _только_ то, что _необходимо_ для работы фичи.
В таком случае задачи, действительно, иногда будут делаться раньше срока. И у вас действительно будут сходиться проекты.
Нарисовали мы себе красивого ганта, смотрим на него, любуемся, а он устаревает. Где-то в этом ганте лежит большая вкусная задача на две недели плотненькой разработки. Ведущий программист Василий с предвкушением берёт эту задачу из бэклога и начинает её делать. Через пятьдесят минут после начала Василий понимает, что для завершения этой достаточно вот в этом вот файлике вот эту вот строчечку поправить и заработает по спеке. Через три часа Василий уже открыл пулл-реквест и прошёл все тесты.
В реальной жизни далее возможны два исхода. Василий говорит ПМ'у, что задача была оценена неверно и уже готова, берёт следующую большую вкусную задачу и делает. Либо, по закону Паркинсона, Василий умудряется потратить время до дедлайна по задаче "с пользой". Нам интересно второе.
Василий окинул бэклог беглым взглядом. Больше никаких больших, вкусных задач в этом месяце не предвиделось. Осталась одна фигня, — подумал он, — если уж мы ТАКОЕ за день сделали, то мелочевка проскочит вообще незамеченной. Всё потому, что я крутой специалист, как никак ведущий разработчик. А вот зато эту большую вкусную задачу в таком виде мержить нельзя, просто стыдно! Мидлы засмеют. Надо вот тут выделить класс, здесь функции вынести в отдельный класс, и вообще, как-то плохо этот кусок написан, надо молодым бойскаут рул показать.
Василий садится за небольшой рефакторинг. Время есть, запас большой, может себе позволить. Через четыре часа он замечает, что можно очень круто обобщить вот этот кусок и тогда можно будет закрыть еще и тикет, который висит с позапрошлого года — всё руки не доходили. Но тут что-то тесты покраснели. Надо бы исправить. Ой, а тесты-то какие плохие! Ну кто так делает? Уф, всему надо учить, даже тесты за ними рефачить приходится.
Пока Василий рефачил, делал какие-то крутые, но никому не нужные фичи (в смысле никому не нужна конфигурация размера кеша http-заголовков??), чинил тесты и учил молодежь, как делать пулл-реквесты на 4к LOC, прошло довольно много времени. Возможно, Василий даже умудрился опоздать к дедлайну, потому что опять забыл заложить время на UA-тестирование.
Как же можно этого избежать? Нужно контролировать скоуп! Должна быть написана спека. Спека это просто, человеческим языком объяснение, что должна делать система. Вход, выход, сайд-эффекты. Круто, если будет еще и формальная спека (openapi, матан, jls ch. 17.4, you name it). Но хотя бы словами.
Спека должна быть минималистична в смысле MOVE (Minial Outcome-Value Effor). То есть фича в спеке должна иметь ценность сама по себе (без необходимости делать еще какие-то фичи, можно продавать, как есть), но при этом в ней абсолютный минимум функционала.
Но спеки недостаточно. Нужно жестко следить за тем, чтобы в рамках задачи/фичи не делалось ничего такого, что в задаче не описано. То есть разработчик должен делать _только_ то, что _необходимо_ для работы фичи.
В таком случае задачи, действительно, иногда будут делаться раньше срока. И у вас действительно будут сходиться проекты.
tenchat.ru
Добродетель минимализма: усилия по достижению цели "результат-ценность" — Олег Лыков на TenChat.ru
В постоянно развивающемся мире технологий и методов разработки программного обеспечения одной из повторяющихся тем является минимализм (напишите в комментариях, какие из перечисленных понятий вам известны):
Минимальный жизнеспособный продукт (MVP)
Минимально…
Минимальный жизнеспособный продукт (MVP)
Минимально…
❤5👍1🥰1
Что там про школы мысли-то?
Вот коллега пишет про дедлайны. Канал, кстати, совершенно замечательный, коллега тоже, подписывайтесь!
Если коротко, то его идея заключается в том, что нужно по каждой задаче ставить жесткий дедлайн и спрашивать за него.
Я вынужден здесь поспорить с тем, что это работает. Несколько мыслей.
1. Когда дедлайн _реально_ жесткий, есть последствия. Вам не заплатят денег, уволят с работы,четвертуют лида. Когда дедлайн "жесткий", вы максимум получите айяйяй и час в углу на горохе.
2. Когда делайн _обоснован_, люди _верят_, что это дедлайн и делают работу. Иначе это просто best effort.
3. Мы тут с вами выясняли, что никто не умеет оценивать. Некоторые, кстати, верят, что умеют или что могут научиться. Но пока что никто не умеет. А значит обязательно будут ошибки с дедлайнами. В обе стороны.Кого будут наказывать за хреновые оценки, впрочем, не уточняется.
4. В качестве способа достижения дедлайна указывается срезание углов и уменьшение скоупа. У меня вопрос: если что-то можно вырезать из скоупа, то почему бы не вырезать это с критического пути сразу? А всё nice-to-have'овое доложить в ганта где-нибудь с краешку, на случай внезапно освободившихся ресурсов.
5. Если _реально_ эскалировать всё подряд, то можно доэскалироваться. Как мы тут с вами знаем, подавляющее большинство работы в компании можно вообще не делать, будет только лучше. А если на каждую фигню отнимать время руководителей, то на действительно важные ресурса не останется.
Здесь хочется отметить, что требовать эскалации могут задачи на критическом пути. И то не все.
С другой стороны, настоящий хардовый дедлайн мотивирует бежать быстрее, фигачить, не шататься праздно между кофепойнтом и бильярдной. Но он еще и мотивирует работать сутками, ведь иначе секир башка — нет ножек, нет мультиков. Придется новую работу искать. Тут либо трусы, либо крестик.
Вот чего, как мне кажется, _на_самом_деле_ хочется добиться, так это "ощущения спешки". То есть выгорать и героически затаскивать всё за одну ночь не нужно, но и прохлаждаться некогда — конкуренты не спят (они роботы на основе LLM ), опаздываем, ребята.
Вот коллега пишет про дедлайны. Канал, кстати, совершенно замечательный, коллега тоже, подписывайтесь!
Если коротко, то его идея заключается в том, что нужно по каждой задаче ставить жесткий дедлайн и спрашивать за него.
Я вынужден здесь поспорить с тем, что это работает. Несколько мыслей.
1. Когда дедлайн _реально_ жесткий, есть последствия. Вам не заплатят денег, уволят с работы,
2. Когда делайн _обоснован_, люди _верят_, что это дедлайн и делают работу. Иначе это просто best effort.
3. Мы тут с вами выясняли, что никто не умеет оценивать. Некоторые, кстати, верят, что умеют или что могут научиться. Но пока что никто не умеет. А значит обязательно будут ошибки с дедлайнами. В обе стороны.
4. В качестве способа достижения дедлайна указывается срезание углов и уменьшение скоупа. У меня вопрос: если что-то можно вырезать из скоупа, то почему бы не вырезать это с критического пути сразу? А всё nice-to-have'овое доложить в ганта где-нибудь с краешку, на случай внезапно освободившихся ресурсов.
5. Если _реально_ эскалировать всё подряд, то можно доэскалироваться. Как мы тут с вами знаем, подавляющее большинство работы в компании можно вообще не делать, будет только лучше. А если на каждую фигню отнимать время руководителей, то на действительно важные ресурса не останется.
Здесь хочется отметить, что требовать эскалации могут задачи на критическом пути. И то не все.
С другой стороны, настоящий хардовый дедлайн мотивирует бежать быстрее, фигачить, не шататься праздно между кофепойнтом и бильярдной. Но он еще и мотивирует работать сутками, ведь иначе секир башка — нет ножек, нет мультиков. Придется новую работу искать. Тут либо трусы, либо крестик.
Вот чего, как мне кажется, _на_самом_деле_ хочется добиться, так это "ощущения спешки". То есть выгорать и героически затаскивать всё за одну ночь не нужно, но и прохлаждаться некогда — конкуренты не спят (
Telegram
Lead’s Notes
О культуре дедлайнов
Иногда лиды, инженеры и менеджеры мысленно делят дедлайна на два типа:
1. Жесткие
Через неделю наш софт заблокируют в стране, если мы не поменяем X / завтра выйдет законопроект, требующий от нас Y / большой клиент расторгнет контракт…
Иногда лиды, инженеры и менеджеры мысленно делят дедлайна на два типа:
1. Жесткие
Через неделю наш софт заблокируют в стране, если мы не поменяем X / завтра выйдет законопроект, требующий от нас Y / большой клиент расторгнет контракт…
👍4
Ещё есть такие периоды, когда вообще работать не можешь. Даже если много денег обещали. Даже если отобрать. В такие периоды важно делать хоть что-то: хоть коммитик, хоть документик, хоть кнопочку. Главное, начать. Не решить начать, а начать.
Тут никакие дедлайны не помогают, к сожалению.
Тут никакие дедлайны не помогают, к сожалению.
❤9👍3🤔2
Сегодня защитились мои ребята магистранты. Двое получили отлично, ещё двое капельку не дотянули до отла и получили хорошо (7) отл начинается с 8 , один решил не защищаться в этом году по итогам предзащиты.
Поздравляю ребят! Два года занятий после работы, домашек по выходным и работе над полноценным проектом для диплома наконец-то окончены.
Получилось хорошо, сделали рабочий прототип, расписали реалистичный роадмап, можно даже пробовать это развивать в реальный бизнес.
Что мне особенно нравится в этом проекте: бизнес-план, маркетинговая компания, развитие ИТ-систем — всё связано между собой. То есть из работ ребят совершенно ясно, почему и в какой момент будет сделана та или иная фича, и как и когда изменится архитектура приложения, как будет меняться позиционирование на рынке. Я доволен.
Пока мне это достоверно не известно, но думаю, что получилась одна из самых сильных работ на потоке. Спасибо за работу, господа магистры 😊
Поздравляю ребят! Два года занятий после работы, домашек по выходным и работе над полноценным проектом для диплома наконец-то окончены.
Получилось хорошо, сделали рабочий прототип, расписали реалистичный роадмап, можно даже пробовать это развивать в реальный бизнес.
Что мне особенно нравится в этом проекте: бизнес-план, маркетинговая компания, развитие ИТ-систем — всё связано между собой. То есть из работ ребят совершенно ясно, почему и в какой момент будет сделана та или иная фича, и как и когда изменится архитектура приложения, как будет меняться позиционирование на рынке. Я доволен.
Пока мне это достоверно не известно, но думаю, что получилась одна из самых сильных работ на потоке. Спасибо за работу, господа магистры 😊
👍10🎉9🤝2❤1🔥1
Forwarded from Media Rare
#менеджмент #лайфхаки
Памятка по текстам, графикам, слайдам и обмену информацией на работе
«Письмо это вышло более длинным только потому, что у меня не было времени написать короче» Блез Паскаль
Спасибо одному из членов моей команды, который вдохновил на этот пост простым тезисом "Ром, зачем ты раздражаешься на оформление материалов, если ни разу не формулировал команде требования к ним". Задумайтесь, сколько мы тратим лишнего времени, чтобы разобраться в чужих плохо структурированных материалах, тупим, начинаем лениво перемещать взгляд между строчками текста и в итоге голосом переливаем из пустого в порожнее 🙂
----
Общие правила и тексты
0. Executive summary первым абзацем/слайдом, если контента на 30+ минут дискуссии
1. Top-down коммуникация = от общего к частному. Сверху пишем самое важное, например: "мы перенесли запуск, но сделаем больше GMV", а уже потом детали зачем/почему/как
2. Заменяйте определения данными (не «увеличенная производительность», а «сократили задержку на стороне сервера с 10 до 1 мс»)
3. Не размывайте формулировки (не «почти все потребители», а «87% подписчиков Prime»)
4. Есть только четыре вида ответов на вопрос: «Да», «Нет», число, «я не знаю» (и вернусь, когда выясню)
5. Числа могут содержать максимум 3 цифры (3 496 тыс --> 3,5 млн)
6. Шрифт везде одного размера. Хотите что-то выделить - сделайте жирным/курсивом/заливкой
7. Месяцы людям намного удобнее воспринимать буквами08.11.2023 --> 8 Nov 2023
8. Не нумеруйте в ганте/графике недели от 1 до N, если не хотите специально помучить коллег. Пишите явно: 23 Oct, 30 Oct, 06 Nov, ...
9. Ко встрече должен быть прерид. Правилом хорошего тона считается прерид за сутки до встречи в календаре или хотя бы в ночь до нее. В идеале еще описать какое решение должно быть принято
10. Пишите коммитменты и задачи в терминах результата, а не процесса. "В июне делаем проект Х" --> "В июле Х будет Y"
11. Пишите важные нюансы сразу. "Запустили Х" --> "Запустили Х для всех кроме Y"
12. При указании эффектов по нечасто используемым метрикам ставить бенчмарки (чтоб было понятно: хорошо, плохо, нейтрально)
Графики
1. Метрика должна быть понятна даже для ребенка
2. Она должна быть сформулирована и написана на графике понятным русским языком
3. На одном графике 1 метрика и никогда не делать двойную ось Y. Если хотите показать зависимость двух величин - сделайте графики друг под другом
4. Оси должны быть подписаны (аббревиатуры расшифрованы, если это не общеупотребимое GMV etc.)
5. График всегда должны быть от 0 (за исключением очень маленьких флуктуаций а-для uptime 99,9%), чтобы не создавать ощущение манипуляции
Слайды
1. Самая важная мысль должна выноситься в заголовок и быть actionable. "Наше выполнение таргетов" --> "Мы перевыполняем GMV на 15%, но замедлимся в 2025"
2. На одном слайде одна мысль. Если мысли 2, то и слайда сделайте два
3. Контент на слайде должен поддерживать/объяснять заголовок, не просто "нафигачим туда несколько графиков - как-нибудь разберется читатель"
4. Если 2 слайда про одно и то же, то оставлять одинаковое название, но ставить индексы (1/2) и (2/2)
5. Шрифт может быть другого размера только в заголовке слайда и сноске. То есть текст, подзаголовки, подписи графиков итд должны быть одинакового(!) кегля
6. Цвет шрифта – черный, единый дизайн буллитов (точка для первого уровня, тире для второго уровня, бублик – для третьего уровня или иной другой, но унифицированный: каждый уровень сдвигается вправо, буллит выравнивается по тексту предыдущего уровня) + использовать шрифты, доступные всем людям на встрече по умолчанию
7. Не забывать про нумерацию слайдов
8. Добавлять слайды разделители между блоками/темами
----
Пункты будут дополняться, оставлю в канале запин с этим постом. Пользуйтесь и распространяйте в ваших командах/компаниях, чтобы всем стало удобнее читать и понимать друг друга!
@media_rare
Памятка по текстам, графикам, слайдам и обмену информацией на работе
«Письмо это вышло более длинным только потому, что у меня не было времени написать короче» Блез Паскаль
Спасибо одному из членов моей команды, который вдохновил на этот пост простым тезисом "Ром, зачем ты раздражаешься на оформление материалов, если ни разу не формулировал команде требования к ним". Задумайтесь, сколько мы тратим лишнего времени, чтобы разобраться в чужих плохо структурированных материалах, тупим, начинаем лениво перемещать взгляд между строчками текста и в итоге голосом переливаем из пустого в порожнее 🙂
----
Общие правила и тексты
0. Executive summary первым абзацем/слайдом, если контента на 30+ минут дискуссии
1. Top-down коммуникация = от общего к частному. Сверху пишем самое важное, например: "мы перенесли запуск, но сделаем больше GMV", а уже потом детали зачем/почему/как
2. Заменяйте определения данными (не «увеличенная производительность», а «сократили задержку на стороне сервера с 10 до 1 мс»)
3. Не размывайте формулировки (не «почти все потребители», а «87% подписчиков Prime»)
4. Есть только четыре вида ответов на вопрос: «Да», «Нет», число, «я не знаю» (и вернусь, когда выясню)
5. Числа могут содержать максимум 3 цифры (
6. Шрифт везде одного размера. Хотите что-то выделить - сделайте жирным/курсивом/заливкой
7. Месяцы людям намного удобнее воспринимать буквами
8. Не нумеруйте в ганте/графике недели от 1 до N, если не хотите специально помучить коллег. Пишите явно: 23 Oct, 30 Oct, 06 Nov, ...
9. Ко встрече должен быть прерид. Правилом хорошего тона считается прерид за сутки до встречи в календаре или хотя бы в ночь до нее. В идеале еще описать какое решение должно быть принято
10. Пишите коммитменты и задачи в терминах результата, а не процесса. "
11. Пишите важные нюансы сразу. "
12. При указании эффектов по нечасто используемым метрикам ставить бенчмарки (чтоб было понятно: хорошо, плохо, нейтрально)
Графики
1. Метрика должна быть понятна даже для ребенка
2. Она должна быть сформулирована и написана на графике понятным русским языком
3. На одном графике 1 метрика и никогда не делать двойную ось Y. Если хотите показать зависимость двух величин - сделайте графики друг под другом
4. Оси должны быть подписаны (аббревиатуры расшифрованы, если это не общеупотребимое GMV etc.)
5. График всегда должны быть от 0 (за исключением очень маленьких флуктуаций а-для uptime 99,9%), чтобы не создавать ощущение манипуляции
Слайды
1. Самая важная мысль должна выноситься в заголовок и быть actionable. "
2. На одном слайде одна мысль. Если мысли 2, то и слайда сделайте два
3. Контент на слайде должен поддерживать/объяснять заголовок, не просто "нафигачим туда несколько графиков - как-нибудь разберется читатель"
4. Если 2 слайда про одно и то же, то оставлять одинаковое название, но ставить индексы (1/2) и (2/2)
5. Шрифт может быть другого размера только в заголовке слайда и сноске. То есть текст, подзаголовки, подписи графиков итд должны быть одинакового(!) кегля
6. Цвет шрифта – черный, единый дизайн буллитов (точка для первого уровня, тире для второго уровня, бублик – для третьего уровня или иной другой, но унифицированный: каждый уровень сдвигается вправо, буллит выравнивается по тексту предыдущего уровня) + использовать шрифты, доступные всем людям на встрече по умолчанию
7. Не забывать про нумерацию слайдов
8. Добавлять слайды разделители между блоками/темами
----
Пункты будут дополняться, оставлю в канале запин с этим постом. Пользуйтесь и распространяйте в ваших командах/компаниях, чтобы всем стало удобнее читать и понимать друг друга!
@media_rare
👍9❤2🎉2🔥1
Книжка топ, насколько раз ее рекомендовал на разных площадках. Отличная возможность изучить её. Касательно физики она сильно устарела, но лучше только чтение актуальных статей (за последние года два максимум), поэтому не важно. Можно поразбираться и на ЯМР.
Forwarded from Boris Burkov
Семинар “Квантовые вычисления и квантовая теория информации”
Суть: мы собираем клуб-вебинар для интересующихся квантовыми вычислениями.
Формат: Каждые 2 недели читаем 1-2 главы (~60-80 страниц) классического учебника Нильсена - Чуанга (подпольная кличка “Mike & Ike”) по квантовым вычислениям и квантовой информации. Раз в 2 недели проводим вебинар, на котором докладчик и ведущий семинара, опираясь на презентацию/jupyter-ноутбук, своими словами пересказывают содержание прочитанной главы и помогают участникам преодолеть затруднения.
Бэкграунд: пригодятся твердые знания линейной алгебры (не повредит понимание определителей, следов, норм, унитарных операторов, преобразований Фурье) и теории вероятностей.
Как участвовать: Нужно зарегистрироваться в гугл-форме, после чего вы будете добавлены в группу семинара в телеграме. Там будут появляться ссылки на вебинары и можно обсуждать возникающие вопросы. Планируется 8 семинаров за 4 месяца.
[форма регистрации] [гитхаб с расписанием и материалами семинаров] [книга]
Суть: мы собираем клуб-вебинар для интересующихся квантовыми вычислениями.
Формат: Каждые 2 недели читаем 1-2 главы (~60-80 страниц) классического учебника Нильсена - Чуанга (подпольная кличка “Mike & Ike”) по квантовым вычислениям и квантовой информации. Раз в 2 недели проводим вебинар, на котором докладчик и ведущий семинара, опираясь на презентацию/jupyter-ноутбук, своими словами пересказывают содержание прочитанной главы и помогают участникам преодолеть затруднения.
Бэкграунд: пригодятся твердые знания линейной алгебры (не повредит понимание определителей, следов, норм, унитарных операторов, преобразований Фурье) и теории вероятностей.
Как участвовать: Нужно зарегистрироваться в гугл-форме, после чего вы будете добавлены в группу семинара в телеграме. Там будут появляться ссылки на вебинары и можно обсуждать возникающие вопросы. Планируется 8 семинаров за 4 месяца.
[форма регистрации] [гитхаб с расписанием и материалами семинаров] [книга]
Стори пойнты не работают
Планирование — это риск менеджмент
Решения принимаем насколько это целесообразно позже, чтобы быть более информированными
У разработчика нет 40 рабочих часов в неделю, оценивать сроки никто не умеет, а на пропускную способность команды влияет куча факторов
Математика нам говорит, что проекты чудесными образом сходятся к сроку, если этапам разрешить заканчиваться досрочно
Таймбоксинг < Скоупбоксинга
Пока ощущение, что ничего не работает, мы обречены, сроки не оцениваются, в дедлайны не попадается! Ужас!
Бизнесу вообще-то надо знать, когда примерно будет готово. Ну знаете, маркетинговые компании там, субсидирования проектов, планирование ликвидных средств — вот это вот всё. А мы такие: мы программисты, профессия творческая, вот посмотрите — quant valerian написал, что ничего не работает!
На самом деле у меня есть ответ. Для того, чтобы запланировать проект и назвать сроки нужен простой советский...
Планирование — это риск менеджмент
Решения принимаем насколько это целесообразно позже, чтобы быть более информированными
У разработчика нет 40 рабочих часов в неделю, оценивать сроки никто не умеет, а на пропускную способность команды влияет куча факторов
Математика нам говорит, что проекты чудесными образом сходятся к сроку, если этапам разрешить заканчиваться досрочно
Таймбоксинг < Скоупбоксинга
Пока ощущение, что ничего не работает, мы обречены, сроки не оцениваются, в дедлайны не попадается! Ужас!
Бизнесу вообще-то надо знать, когда примерно будет готово. Ну знаете, маркетинговые компании там, субсидирования проектов, планирование ликвидных средств — вот это вот всё. А мы такие: мы программисты, профессия творческая, вот посмотрите — quant valerian написал, что ничего не работает!
На самом деле у меня есть ответ. Для того, чтобы запланировать проект и назвать сроки нужен простой советский...
Telegram
Quant Valerian
Убираем стори пойнты
Так вот, завёл такую штуку. И вот по-тихоньку лью туда наши практики. Дошло дело до стори пойнтов. И такое дело... Стори пойнты не нужны.
- У нас не скрам, мы не планируем спринт.
- Мы не можем планировать квартал или полугодие в sp…
Так вот, завёл такую штуку. И вот по-тихоньку лью туда наши практики. Дошло дело до стори пойнтов. И такое дело... Стори пойнты не нужны.
- У нас не скрам, мы не планируем спринт.
- Мы не можем планировать квартал или полугодие в sp…
😁8👍1