Комментарии 10
В общем-то все написано верно, но, думаю, что минусов отхватите от тех, кто не любит "гореть" идеей и видеть внесённые изменения. Большинство пришло за деньгами, а не за развитием (
А как вы поступаете с разработчиками которые уходят из команды стартапа и уносят знания?
как Иван Грозный с зодчими храма Василия Блаженного
Вообще никак, они просто уходят в свободное плаванье. У людей бывают другие ценности, это нормально, так устроен мир.
Мы со своей стороны стараемся предотвращать такие вещи, и тут два основных пути:
1. Развивать систему шеринга знаний в команде.
2. Совершенствоваться и лучше чекать систему ценностей кандидата на этапе отбора. У нас классный продукт и команда, при этом мы даём адекватную зарплату по рынку. Кандидаты, которые гонятся только за цифрой – не для нас, ибо рынке всегда будет кто-то, кто заплатит больше.
Мы со своей стороны стараемся предотвращать такие вещи, и тут два основных пути:
1. Развивать систему шеринга знаний в команде.
2. Совершенствоваться и лучше чекать систему ценностей кандидата на этапе отбора. У нас классный продукт и команда, при этом мы даём адекватную зарплату по рынку. Кандидаты, которые гонятся только за цифрой – не для нас, ибо рынке всегда будет кто-то, кто заплатит больше.
Можно поподробнее насчет урока 2?
1) С точки зрения перечисления проблем вы описали техническую проблему (несовместимость API, несовместимость технологий), но при этом одновременно используете выражения про какую-то другую организационную проблему («отказываться от доброй половины свежесобранной команды», «нужно четко планировать расширение команды»). Это просто параллельные проблемы, которые хронологически наложились друг на друга, или проблемы с причинно-следственной связью?
2) Могли ли руководители в тот момент в прошлом с той информацией, которой они обладали, принять более эффективное решение? «Задним числом все умные». Можете пояснить, какую важную информацию или сигналы руководители проигнорировали по неопытности?
1) С точки зрения перечисления проблем вы описали техническую проблему (несовместимость API, несовместимость технологий), но при этом одновременно используете выражения про какую-то другую организационную проблему («отказываться от доброй половины свежесобранной команды», «нужно четко планировать расширение команды»). Это просто параллельные проблемы, которые хронологически наложились друг на друга, или проблемы с причинно-следственной связью?
2) Могли ли руководители в тот момент в прошлом с той информацией, которой они обладали, принять более эффективное решение? «Задним числом все умные». Можете пояснить, какую важную информацию или сигналы руководители проигнорировали по неопытности?
Спасибо за интересные вопросы!
1) Это действительно проблемы с причинно-следственной связью. Из-за того, что мы не обеспечили совместимость технологий, нам пришлось отказаться от команды, которая работала на других технологиях. В момент принятия решения, сделать это было проще, чем совмещать.
2) Да, конечно могли. Основной сигнал – это когда у вас в голове появляется мысль «Хе, там какие-то ребятам в моей команде/подразделении занимаются непонятно чем». Это верный знак, что нужно найти ответ на этот вопрос плюс поработать над увеличением прозрачности процессов в компании в целом.
1) Это действительно проблемы с причинно-следственной связью. Из-за того, что мы не обеспечили совместимость технологий, нам пришлось отказаться от команды, которая работала на других технологиях. В момент принятия решения, сделать это было проще, чем совмещать.
2) Да, конечно могли. Основной сигнал – это когда у вас в голове появляется мысль «Хе, там какие-то ребятам в моей команде/подразделении занимаются непонятно чем». Это верный знак, что нужно найти ответ на этот вопрос плюс поработать над увеличением прозрачности процессов в компании в целом.
Из-за того, что мы не обеспечили совместимость технологий, нам пришлось отказаться от команды, которая работала на других технологиях.
Звучит очень странно, что вы оказались перед выбором «либо продолжать использовать технологию Б, либо на мороз». Т.е. вы будто уже начинаете разработку по формуле «если этот проект не получится, то сотрудников перевести на другой проект не получится».
Я правильно понимаю, что разработка любого проекта у вас происходит в полной свободе выбора технологий со стороны команды? Кто хочет, тот выбирает Java, кто хочет — PHP, кто хочет — Rust. На стек технологий ограничений со стороны СТО нет?
Нет, конечно, ограничения на возможные стеки были и есть.
Так комбинация факторов сработала – разные стеки (изначально все задумывалось в одном варианте под лозунгом «а как максимально быстро проверить гипотезу»), неправильно спроектированная архитектура, изменившиеся в процессе бизнес-требования, опыт и компетенция собранной команды. В итоге решение переделывать и перетаскивать на стек основного приложения было непростым, но в той ситуации наиболее оптимальным при существующих рисках.
На самом деле я сейчас описываю вам в паре предложений события нескольких месяцев. Если интересна тема – готова уделить время и поделиться с вами своим опытом, который вынесла из этой конкретной ситуации. Кейс был очень забавный.
Так комбинация факторов сработала – разные стеки (изначально все задумывалось в одном варианте под лозунгом «а как максимально быстро проверить гипотезу»), неправильно спроектированная архитектура, изменившиеся в процессе бизнес-требования, опыт и компетенция собранной команды. В итоге решение переделывать и перетаскивать на стек основного приложения было непростым, но в той ситуации наиболее оптимальным при существующих рисках.
На самом деле я сейчас описываю вам в паре предложений события нескольких месяцев. Если интересна тема – готова уделить время и поделиться с вами своим опытом, который вынесла из этой конкретной ситуации. Кейс был очень забавный.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Расширение технической команды в растущем стартапе: проблемы и решения