Даже если вы, опять же, небольшая компания, что вам мешает, условно, выступать на тех же самых конференциях, что-то рассказывать, писать? Вопрос, скорее, желания.
Кажется, что это взгляд на проблему только с одной стороны. Выступить на конференциии не так уж и просто. Ведь плохое выступление не сработает, да? Что-то внятное рассказать может только смышленый ёж. Ежа придется отвлечь от продуктовых задач, потратить время на подготовку выступления, потратить время и деньги на обучение, как правильно выступать и т.д., и т.п.
С написанием тех же статей та еще морока. Никто не хочет читать написанную на коленке статью. Хорошую статью надо написать, вычитать, поправить стиль, отточить формулировки, редактура-корректура и вот это вот всё.
Про онбординг та же история. Выстроить работающую процедуру онбординга это тоже время и деньги одних из самых дорогих специалистов, это итеративный процесс, который может и будет длиться годами.
Я к тому, что это все-таки не вопрос желания, а вопрос наличия ресурсов, не у всех он есть.
К сожалению, такой подход работает только, если ваша команда почти идеально оценивает задачи. Если точность оценки задач не идеальна (а обычно это так), то она будет сильно аффектить решение той проблемы, которую вы изначально решали - "а почему не все фичи допилили?" Да потому что задачи оценили неправильно.
Истпытываю ощущение, что капасити команды можно определить без расчетов, просто пробежав вместе с командой несколько спринтов и посмотрев, сколько часов продуктовой разработки на человека успеваем сделать по фактически списанным часам на задачу.
У меня был такой опыт: мы планировали 26 часов на человека в неделю. Пришел шеф и говорит, а давайте по 30 часов. Мы такие, да легко. Запланировали по 30. Успели все равно по 26. Такие дела.
У меня через год стал барахлить регулятор громкости — в положении максимальной громкости пропадает контакт, от чего пропадает звук в ушах. А так наушники агонь!
Это был, наверное, 1985-86 год. До школы точно. Иногда отец брал меня к себе на работу в лабораторию кафедры Общей физики и ядерного синтеза Московского Энергетического Института. И там можно было порубиться в pacman-а на крутейшем старинном компе!
Пакмэн был реализован с помощью псевдографики, а сам комп был похож на половинку пианино, только с клавиатурой и круглым электронно-лучевым черно-белым дисплеем. Грузился он вроде с восьмидюймовых дискет (могу путать, но вроде бы эти дискеты были больше, чем получившие потом повсеместное распространение пятидюймовки). Но вот что точно помню – ресет там нажимался ногой!
И это было просто удивительно! Прикосновение к чему-то волшебному! Предположу, что уже тогда моя профессиональная судьба была предопределена…
Подскажи, пожалуйста, на сколько была репрезентативная выборка пользователей, которых вы позвали на встречу? Ведь если в системе тысячи пользователей, то хотелки нескольких из них могут быть очень индивидуальными и не будут отражать потребности большинства юзеров.
Проще говоря, расскажи, пожалуйста, немного о том, с какими проблемами при работе с пользователями вы столкнулись. Наверняка был какой-то элемент преодоления трудностей.
В предложении «Мы дублируем те сервисы, для которых расходы на дополнительный сервер или БД выше, чем ожидаемые риски от падений» видимо «не» пропущено, «мы НЕ дублируем». По смыслу же должно быть, что мы не дублируем то, падение чего стоит дешевле, чем резервное железо, да?
Денис, спасибо за статью! Было интересно.
Не приходилось сталкиваться с ошибками в старом коде, когда сломали что-то незначительное, но связанное с деньгами/поездками, но очень давно?
Пример из другой предметной области, но тем не менее — в каком-то определенном хитром случае подписки перестали продляться или комиссия перестала списываться. То есть где-то течет, но чуть-чуть и на графиках этого после релиза не заметно и мониторинг не замечает.
Находишь такое через год, умножаешь на 365 вроде бы небольшую сумму потерь за день, и волосы начинают шевелиться на самых нескромных местах от масштабов потерь. Самые неприятные, на мой взгляд, аварии.
Из организационных штук хотелось бы узнать, как в СитиМобил устроен онбординг и перформанс ревью. На сколько я понимаю, команда достаточно быстро растет, и отладкой этих процессов в том или ином виде приходится заниматься.
Команда большая уже. Как используете скрам? Как организуете взаимодействие на стыке скрам-команд?
А из технических штук было бы интересно послушать, что думаете на счет микросервисной архитектуры? По описанию похоже, что под капотом у СМ монолит.
Интересно, как распределены роли и ответственность между командами. Как принимаются архитектурные решения? Есть ли какой-то клуб анонимных архитекторов?
Ох, не просто у вас там с SAP. Спасибо за пост!
В веб-разработке применяю такой способ получить быструю оценку себестоимости разработки сервиса: ФОТ + аренда и прочие расходы, делим на количество сотрудников в компании, получаем стоимость часа. А дальше пляшем уже от трудозатрат.
Если стоимость часа составляет, скажем, 1000 рублей, то разработка фичи в течение 10 часов обойдется компании на 10к.
Кажется, что это взгляд на проблему только с одной стороны.
Выступить на конференциии не так уж и просто. Ведь плохое выступление не сработает, да? Что-то внятное рассказать может только смышленый ёж. Ежа придется отвлечь от продуктовых задач, потратить время на подготовку выступления, потратить время и деньги на обучение, как правильно выступать и т.д., и т.п.
С написанием тех же статей та еще морока. Никто не хочет читать написанную на коленке статью. Хорошую статью надо написать, вычитать, поправить стиль, отточить формулировки, редактура-корректура и вот это вот всё.
Про онбординг та же история. Выстроить работающую процедуру онбординга это тоже время и деньги одних из самых дорогих специалистов, это итеративный процесс, который может и будет длиться годами.
Я к тому, что это все-таки не вопрос желания, а вопрос наличия ресурсов, не у всех он есть.
Канбаааан! Две чачи этому джигиту!
К сожалению, такой подход работает только, если ваша команда почти идеально оценивает задачи. Если точность оценки задач не идеальна (а обычно это так), то она будет сильно аффектить решение той проблемы, которую вы изначально решали - "а почему не все фичи допилили?" Да потому что задачи оценили неправильно.
Истпытываю ощущение, что капасити команды можно определить без расчетов, просто пробежав вместе с командой несколько спринтов и посмотрев, сколько часов продуктовой разработки на человека успеваем сделать по фактически списанным часам на задачу.
У меня был такой опыт: мы планировали 26 часов на человека в неделю. Пришел шеф и говорит, а давайте по 30 часов. Мы такие, да легко. Запланировали по 30. Успели все равно по 26. Такие дела.
В тему поста.
Пакмэн был реализован с помощью псевдографики, а сам комп был похож на половинку пианино, только с клавиатурой и круглым электронно-лучевым черно-белым дисплеем. Грузился он вроде с восьмидюймовых дискет (могу путать, но вроде бы эти дискеты были больше, чем получившие потом повсеместное распространение пятидюймовки). Но вот что точно помню – ресет там нажимался ногой!
И это было просто удивительно! Прикосновение к чему-то волшебному! Предположу, что уже тогда моя профессиональная судьба была предопределена…
Продолжайте делиться опытом — это очень интересно.
Подскажи, пожалуйста, на сколько была репрезентативная выборка пользователей, которых вы позвали на встречу? Ведь если в системе тысячи пользователей, то хотелки нескольких из них могут быть очень индивидуальными и не будут отражать потребности большинства юзеров.
Проще говоря, расскажи, пожалуйста, немного о том, с какими проблемами при работе с пользователями вы столкнулись. Наверняка был какой-то элемент преодоления трудностей.
Спасибо!
Клуб риторики я уже у вас подсмотрел, а теперь и про фидбек возьму на заметку.
Супер! Спасибо еще раз!
Правильно понимаю, что в команде нет ни менеджера проекта, ни скрам-мастера? Получается, что фичекрайние как раз и выполняют их роль, так?
Не приходилось сталкиваться с ошибками в старом коде, когда сломали что-то незначительное, но связанное с деньгами/поездками, но очень давно?
Пример из другой предметной области, но тем не менее — в каком-то определенном хитром случае подписки перестали продляться или комиссия перестала списываться. То есть где-то течет, но чуть-чуть и на графиках этого после релиза не заметно и мониторинг не замечает.
Находишь такое через год, умножаешь на 365 вроде бы небольшую сумму потерь за день, и волосы начинают шевелиться на самых нескромных местах от масштабов потерь. Самые неприятные, на мой взгляд, аварии.
Спасибо большое!
Из организационных штук хотелось бы узнать, как в СитиМобил устроен онбординг и перформанс ревью. На сколько я понимаю, команда достаточно быстро растет, и отладкой этих процессов в том или ином виде приходится заниматься.
Команда большая уже. Как используете скрам? Как организуете взаимодействие на стыке скрам-команд?
А из технических штук было бы интересно послушать, что думаете на счет микросервисной архитектуры? По описанию похоже, что под капотом у СМ монолит.
Интересно, как распределены роли и ответственность между командами. Как принимаются архитектурные решения? Есть ли какой-то клуб анонимных архитекторов?
Про отношение к автотестам хотелось бы услышать.
Буду ждать продолжения!
В веб-разработке применяю такой способ получить быструю оценку себестоимости разработки сервиса: ФОТ + аренда и прочие расходы, делим на количество сотрудников в компании, получаем стоимость часа. А дальше пляшем уже от трудозатрат.
Если стоимость часа составляет, скажем, 1000 рублей, то разработка фичи в течение 10 часов обойдется компании на 10к.