Comments 18
Отечественные ОС – это не просто замена западного ПО, а целый пласт инфраструктурных изменений, и это самое сложное. Многие забывают, что переход – это не только установка новой системы, но и совместимость с софтом, интеграция, обучение персонала. Даже если ОС технологически хороша, без нормальной экосистемы вокруг неё (драйверов, сервисов, поддержки) процесс внедрения превращается в квест. Главное, чтобы это был не просто разовый проект, а долгосрочная стратегия, иначе через пару лет снова придётся что-то менять
Добрый день. Не понимаю при чем тут ОС, но отвечу.
В компании Инферит есть своя ОС. У нас сильная техническая команда и профессионалы в бизнес-блоке. Есть широкий список совместимостей с лидерами своих сфер. Мы 10 лет оказываем поддержку дистрибутива мажорной версии, а планы лежат гораздо дальше этих 10-и лет.
Загуглите «МСВСфера» или «Инферит ОС» и ознакомьтесь. Расписывать подробнее не буду, так как статья совсем про другое.
Спасибо за комментарий и понимание :)
«Идеальная архитектура» - та, что решает задачи бизнеса здесь и сейчас
очень быстро, но недалеко поедете, и посреди пути увязнете в техдолге и багах
есть определенный горизонт планирования изменений, и чем матерее разработчик - тем дальше смотрит. если вы будете насильно обрубать ему горизонт до "здесь и сейчас" - он уйдёт.
вы его замените теми, кто поудобнее, и тоже про "здесь и сейчас".
и взвоете, просто не сегодня, а чуть чуть попозже, когда "здесь и сейчас" превратится "вчера же еще работало, надо просто чуть чуть изменить...", и уже не получится
Приветствую.
Мне искренне жаль, что из всей статьи, подлый Хабр, показал вам только это предложение.
Попробуйте обновить страницу, там есть ещё текст, в котором подробно описано, на мой взгляд, идеальное взаимодействие.
По поводу горизонта планирования: стратегия продукта должна ВСЕГДА обсуждаться с СТО. Но статья про другое :)
СТО - Станция Технического Обслуживания
MVP - Most Valuable Player
Это то, что понял из абрревиатур. Судя по заглавию, думал что-то про авто почитать.. Например, как инженеры на станции ТО заставили разработчиков делать долговечные автомобили, а эти долговечные автомобили разрушили бизнес, потому что не ломались.
А в итоге как в старой телепередаче: "что смотрел - ничего не понял".
Как продакт я вижу совершенно другое.
Да, делать рефакторинг просто ради нового фреймворка не стоит, но и забить на технику - прямой путь к тому, что продукт обрастает техдолгом и костылями, для его поддержки и развития будет нужно больше людей, и в итоге пользователи все равно уйдут, но у вас будет огромный штат и обязательства перед сотрудниками.
Продукты, где прототип (не путать с mvp) вырвался из под контроля и оказался на проде, в итоге только дают дорогу конкурентам. Если вы сделаете сейчас какое-то крутое решение, но криво, то да, первые юзеров ваши, но затем я уже по доказанной гипотезе, изученному (за ваш счёт) дизайну, готовому ТЗ сделаю свой сервис, но не кривой и косой, а нормальный. Дальше вопрос только схантить одного из ваших сейлз и можете закрываться))
Собственно можем прямо сейчас видеть как отмирают десятки клонов ноушена и миро, которые расплодились сразу после их ухода. Наклепали за неделю. Но за неделю вышло сделать только то, что обычно делают в туалете. А сделать нормально - это начать заново, уже ни ресурсов, ни времени.
В общем да, нужен баланс и все роли в команде важны, все этом роли могут быть в одном человеке. Но заголовок и первый абзац - кликбейт)
пользователи массово уходят к конкурентам с кривым, но быстрым MVP. Знакомый сценарий?
Неа. А вам знакомый? Поделитесь статистикой.
Приветствую.
Ваш комментарий про статистику - чистейшая манипуляция, но всё-же я отвечу.
Не забывайте, что это статья и элементы клиебейта в заходе присутствуют, а именно в остроте формулировки.
На своем пути я встречал подобные сценарии, видел как желание построить продукт по принципу «я знаю как надо» без внимания на отклик с рынка приводили к краху бизнеса. Инвесторы не готовы вкачивать деньги бесконечно, и зачастую (опираюсь на свой опыт) это приводит к 2-м вариантам: 1. Меняют главу продукта на специалиста с уклоном в бизнес; 2. Оптимизируют расходы за счёт сокращения команды или отказа от продукта (продажа/закрытие).
Рекомендую прочитать оставшуюся часть статьи и попробовать сформировать мнение по ней, а не по заголовку или преамбуле.
Статистики у меня нет, но есть результаты опроса, под этой публикацией, которые говорят о том, что подобное случается не только в тех компаниях, где я был наблюдателям.
Ещё рез проговорю то, что написал в этой же публикации: у меня есть примеры прекрасного СТО (технаря), который смог выдержать баланс между желанием создать отличный продукт и желанием создать бизнес, но статья про другую проблему.
Ваш комментарий про статистику - чистейшая манипуляция
Любой неудобный вопрос это манипуляция, да. Вопрос не в том, что такое бывает, а в том, насколько часто. Может проводились исследования какие-то, может простой опрос хотя бы.
На своем пути я встречал подобные сценарии
Я вот встречал сценарии когда из-за недостатка техскиллов продукт и до альфа версии не доходил. И сценарии когда "бизнес" под видом "развития" творил всякую хрень с нулевым, а то и отрицательным выхлопом. И сценарии с положительным результатом тоже встречал. Разные бывают сценарии.
Рекомендую прочитать оставшуюся часть статьи и попробовать сформировать мнение по ней, а не по заголовку или преамбуле.
Рекомендую давать меньше хамских советов. Дискуссии это не способствует. Мой вопрос и есть концентрированное мнение по всей статье.
«Идеальная архитектура» - та, что решает задачи бизнеса здесь и сейчас
Такой подход вполне может привести к постоянным тормозам и глюкам, а срок внедрения новых фич увеличится в разы. Что тогда скажет бизнес? Технари, которые не понимают бизнеса, видимо будут виноваты. Нужен баланс, причем в разных продуктах разный. В технически простых вещах, баланс будет смещен в сторону бизнеса. В технически сложных в сторону технарей. Сильно влияет длительность жизненного цикла продукта. Да банально что за продукт вообще, из какой отрасли. А еще нужно доверие между людьми и взаимное уважение. А у вас клише про технарей перфекционистов, которые не видят дальше своего носа.
Мне жаль, что вы увидели хамство в моем ответе, приношу извинение.
В остальном, что я вижу в вашем комментарии, мы с Вами, концептуально, имеем единый взгляд на проблематику.
В данной публикации, я не проследовал цель рассказать про все сложности на пути к построению прочной, взаимодополняющей, команды, разбирал конкретную ситуацию (опрос подтверждает, что такое бывает).
А у вас клише про технарей перфекционистов, которые не видят дальше своего носа.
Ниже в комментариях, я уже отвечал про то, что сложности возникают не только с СТО.
Желание продакта «выстроить идеальные процессы» или СТО «сделать идеальный продукт» или бизнеса «заработать здесь и сейчас» — это тоже большая проблема.
В конкретной публикации, я нигде не писал о том, что властный СТО, встречается чаще, чем такой же властный продакт-администратор.
В этой публикации я выбрал конкретный пример с СТО «самодуром» во главе продукта и предлагал решение данной проблемы.
Я нигде не говорил, что все СТО такие или что не бывает примеров с перекосом в другие стороны — конечно бывает. Но, опять же, описывал конкретную ситуацию.
Возможно, в будущем я опишу проблематику связанную с продактом «самодуром» или бизнесменом «впаривателем», но те статьи не будут связаны с этой и наоборот.
Вас про другое спрашивали:
"пользователи массово уходят к конкурентам с кривым, но быстрым MVP. Знакомый сценарий?"
Есть ли у вас статистика, успешного старта с кривым MVP? Т.е. не проверки гипотезы, а именно старта на кривом продукте?
Хуже перфекциониста СТО только менеджер пытающийся вот так идеально организовать работу со своими kpi и кросс-функциональными командами ))) тем же самым по факту занимаетесь и так же тяните проект на дно
Согласен, это тоже проблема. Не согласен с тем, что это хуже и со словом «занимаетесь» в остальном да - Вы правы.
Желание продакта «выстроить идеальные процессы» или СТО «сделать идеальный продукт» или бизнеса «заработать здесь и сейчас» — это крах со временем. Если первые два убивают продукт из-за того, что им не хватает времени на то, чтобы дать финансовый результат, который ждут инвесторы, то третий, показав финансовый результат, без оглядки на обратную связь клиентов, теряет этих же клиентов и доверие инвесторов.
Поэтому я написал про баланс, про косс-функциональное взаимодействие.
При построение бизнеса в долгую, важно иметь три долгосрочные стратегии:
Стратегия развития продукта;
Стратегия развития компании;
Финансовая стратегия (планирование).
А также, не менее важно, уметь реагировать на изменения
Если с этим всем может справиться один гениальный человек — прекрасно, пусть делает, зачем надстраивать доп. процессы если и так всё работает? Но это до момента масштабирования.
В данной же статье, я разобрал конкретный вопрос — желание создать идеальный продукт без оглядки в рынок.
Я сейчас буду душнить, но глава компании — это ваш клиент. Если вы создаете процесс/продукт, который не отвечает на запросы рынка — до свидания.
ваш СТО тратит месяцы на безупречную архитектуру
Это говорит только о полной профнепригодности. Если архитектура действительно безупречная, то на неё не потребуется столько времени. Одна из целей хорошей архитектуры - ускорить и упростить разработку.
Проблема:
Пять тревожных звоночков [когда CTO захватил власть]:
1. Архитектурные паттерны важнее юзабилити;
2. Микросервисы внедряются «на всякий случай»;
[…]
Предложенное решение:
Разделяй и властвуй: зоны ответственности
• СТО — архитектура, […]
———
Вы видите значительные изменения? — А их нет.
Когда СТО захватывает власть: как технический перфекционизм убивает продукт