Чтобы защитить мелкие компании от крупных монополистов не надо создавать кучи и кучи антимонопольных законов. Надо начать с ограничения размера компании по стоимости. Например один миллиард долларов. И сразу решится куча проблем. И с людьми так же - тоже чтобы не больше одного миллиарда у человека.
Поздравляю вас, вы только, что описали принципы planing poker и как вычислять velocity команды. У меня вы свое время ушло 8-10 двухнедельных спринтера, перед тем как velocity команд стабилизировалось.
Это классический случай, когда сроки спрашивать не надо с разработчиков. В таких случаях сроки надо ставить. А разработчики должны их выполнять, жертвуя или качеством или овертаймами, за которые должна платить фирма... Ну а потом отпуска-отгулы и т.д. с одной стороны и тех.долг с другой. Отпуска и отгулы, чтобы компенсировать психологический перегруз it команды.
Вы пишете, что сбор первоначальных требований, можно уместить в 1-3 часа, это получается совсем какой-то маленький проект. И вы делаете это бесплатно. Бесплатно наверное, потому что не предоставляете клиенту продукт.
Но на самом деле продукт можно предоставить - это документ под названием vision. Он должен занимать от одной до трёх страниц и описывать проект широкими мазками. Пишется на основании разговора с одним человеком, основным ЛПР скорее всего. Но я бы сказал что для маленького и простого проекта его можно написать за полдня, если чуть посложнее или побольше то за день, ну а для большого и сложного за два дня. Ну и соответственно три таксы можно озвучивать заказчику на vision. За малый, средний и большой. После того как заказчик одобрит vision - дальше идти будет проще. После написания этого документа станет понятен примерный объем работ, недели или месяцы или годы или десятилетия.
После этого можно оценить сколько будет стоить ТЗ на написание функциональных требований. Написать это ТЗ. Получить согласование от заказчика и уже после этого оценить работу по написанию функциональных требований.
Как говорится, слона надо есть по частям. И после каждого этапа у заказчика за его деньги будет готовый продукт, с которым он может продолжить работу с другим исполнителем.
Можно конечно, попробовать сразу сделать грубую оценку трудоемкости написания ТЗ, на основании первоначального анкетирования - сколько представителей заказчика надо опросить по функционалу приложения(и за какой срок каждый из них сможет передать свои знания, час/день/неделя/полмесяца/месяц), кто у заказчика будет принимать решения о согласовании противоречивых требований от разных представителей заказчика, сколько разных функциональных типов пользователей будет у приложения, сколько примерно функциональных единиц требований будет у каждого типа пользователей. Сколько примерно функциональных единиц будет среди серверных задач(которые выполняются независимо от действий пользователей). И тогда, если в процессе написания функциональных требований какие-то числа будут выше, чем в анкете, то это будет аргументированная позиция для пересмотра стоимости написания функциональных требований.
Если проект рос постепенно, то еще проще развивать framework. Начиная с пяти разработчиков уже точно надо делить на функциональную часть и инструментальную. Часто уже при меньшем количестве разработчиков.
Что касается генерации кода - видишь много тупого бойлерплейтного кода - начинаешь писать генерацию кода из метаданных, сгенерированный код прекрасно умеет жить вместе с написанным разработчиком, если его правильно организовать.
P.S. В большом проекте, где много разных разработчиков нужны стандарты кодирования, чтобы разные куски были написаны одинаково и разработчик мог легко разобраться в чужом коде. Чем больше стандартов, тем больше одинакового кода. Чем больше одинакового кода - тем больше кандидатов или на генерацию или на вынесениюе в инфраструктурную библиотеку.
70 разработчиков фронт-приложения? Вы серьезно? 70 человек в состоянии написать 5-10 приложений, а не одно...
А если серьезно, надо выделить библиотеки(1-2-3-4), в которые вынести нефункциональный код. И нанять туда 4-5 сеньоров, такой команды достаточно, чтобы написать любую необходимую библиотеку.
Функциональные требования требования на фронте очень похожи, напиишите фреймворк, который на основе метаданных будет генерировать код. На это тоже хватит 4-5 сеньоров.
Ну а чтобы писать функционал на метаданных можно уже брать мидлов и даже джунов. На все про все хватит 10-20 человек.
Итого у вас команда в 20-30 человек вместо 70. Управлять ими гораздо проще, менеджеров надо меньше.
Каждому из core team платить конечно придется значительно больше, но в целом ФОТ получится уменьшить раза в полтора. И никакие микрофронты не нужны.
Вуаля!
Не благодарите.
P.S. Следующее приложение на готовом фреймворке можно написать уже гораздо быстрее... Правда современные эффективные менеджеры не имеют обыкновения думать о будущем :-(
А может вопрос неправильно поставлен? Может проблема в том, что команда кросс функциональная? Надо переразбиться в команды по профилю и проблем с код-ревью не будет?
Это у вас не умеют правильно ставить задачи, и декомпозировать большие задачи на средние с четким описанием интерфейсов взаимодействий. Если задачи грамотно поставлены, то разработчик может работать пару недель более-менее независимо. А если нужна коммуникация, то можно обсудить в мессенджере, в режиме сегодня спросил - завтра ответили. Но вопросы должны быть правильными (чтобы правильно задать вопрос надо знать 80% ответа)
А если задачи ставятся кое-как, то и надо обсуждать их каждые 3-4 часа. А это как делать - это я забыл обдумать. А то как делать - я не учел когда постановку писал....
Ничего это не другое... Как раз то самое.... Это ситуация когда здравый смысл заменяется идеями из книги, или от попов или еще от каких-то людей(сущностей).
Когда вместо того, чтобы принимать свои собственные решения, человек отдает принятие части решений на аутсорсинг другой сущности.
можно быть лидом на проекте, и без людей в подчинении. Если ты отвечаешь за все технические решения на проекте и контактируешь с нетехническим руководителем по задачам проекта. И задачи тебе ставятся в бизнес-разрезе, а как их реализовывать ты решаешь сам - ты несомненно лид.
я не знаю в каком бюрократическом мире живёт большинство комментирующих... может в банках или яндексах или на других галерах... А я большую часть жизни работал в небольших компаниях до 50 человек. и отпуска согласовывал по почте или в мессенджере. Заявление на отпуск писал за несколько дней до отпуска и оставлял нас подписью у бухгалтера или секретаря и подписанным его не видел. а иногда забывал написать до отпуска, и писал сразу после отпуска. И расценивать такой уклад как более человеческий, чем подписывать заявление за месяц или того пуще согласовывать график отпусков на год вперёд. Понятие график отпусков было в паре контор где я работал из более, чем десяти, в которых я работал.
а может с другого конца зайти и получить какое-нибудь не токсичное гражданство, хоть через фиктивный брак - а потом с ним уже работу искать за границей.
У меня знакомые и 4 дня в неделю работали и 2 и 2,5-3, правда обычно договаривались на своей работе, на которой уже известно было, что человек нормально работает. Так что проблема скорее всего, только при поиске новой работы, а на старой можно договориться.
Интересно, а токсичные люди воспринимают токсичность других? Или собственная токсичность защищает от проявления токсичности по отношению к себе? Я за 20+ лет не встречал токсичных коллег. Встречал некомпетентных хоть и не часто, тупых изредка, интриганов пару раз.... Обманщиков среди тех кто нанимал несколько раз
Но в целом, на 80-90% атмосфера в компаниях где я работал была приятная и часто были умные люди среди коллег, с которыми было интересно общаться....
я не знаю, насколько легко найти работу. Но я знаю что потребовалось около полугода (правда не самых активных поисков), чтобы найти мидла на Котлине, который умеет программировать. и это на полную удаленку, с плавающим графиком, полностью по ТК. это на зп в 250к. так что не знаю, что там с дефицитом вакансий, а дефицит сотрудников. явно есть.... ну или наши Hr совсем не умеют людей искать. Про хбр и хх они знали и использовали.
не посылал резюме в 2023 году. но при этом 3-4 раза в неделю пишут с предложением рассмотреть вакансию. правда в 60% случаев вакансии не соответствуют моему резюме:-)
Чтобы защитить мелкие компании от крупных монополистов не надо создавать кучи и кучи антимонопольных законов. Надо начать с ограничения размера компании по стоимости. Например один миллиард долларов. И сразу решится куча проблем. И с людьми так же - тоже чтобы не больше одного миллиарда у человека.
Есть такое правило, когда тебе что-то объясняют - записывай. В следующий раз можно будет перечитать и не надо будет спрашивать.
Поздравляю вас, вы только, что описали принципы planing poker и как вычислять velocity команды. У меня вы свое время ушло 8-10 двухнедельных спринтера, перед тем как velocity команд стабилизировалось.
Это классический случай, когда сроки спрашивать не надо с разработчиков. В таких случаях сроки надо ставить. А разработчики должны их выполнять, жертвуя или качеством или овертаймами, за которые должна платить фирма... Ну а потом отпуска-отгулы и т.д. с одной стороны и тех.долг с другой. Отпуска и отгулы, чтобы компенсировать психологический перегруз it команды.
Простите, а вы средненький кнопкодав в faang'e?
13м отложенных за 22 месяца не бьётся со средней ЗП в 400к рублей.
А как простите excel конфликтует с rdp/citrix?
Нельзя поставить excel на виртуалку в облаке около Оракла? И ходить на эту виртуалку через удаленный стол?
Тогда раундтрипы через медленную сеть ограничиваются картинкой, а мешки данных ходят внутри облака и уже не очень важно сколько их.
Вы пишете, что сбор первоначальных требований, можно уместить в 1-3 часа, это получается совсем какой-то маленький проект. И вы делаете это бесплатно. Бесплатно наверное, потому что не предоставляете клиенту продукт.
Но на самом деле продукт можно предоставить - это документ под названием vision. Он должен занимать от одной до трёх страниц и описывать проект широкими мазками. Пишется на основании разговора с одним человеком, основным ЛПР скорее всего. Но я бы сказал что для маленького и простого проекта его можно написать за полдня, если чуть посложнее или побольше то за день, ну а для большого и сложного за два дня. Ну и соответственно три таксы можно озвучивать заказчику на vision. За малый, средний и большой. После того как заказчик одобрит vision - дальше идти будет проще. После написания этого документа станет понятен примерный объем работ, недели или месяцы или годы или десятилетия.
После этого можно оценить сколько будет стоить ТЗ на написание функциональных требований. Написать это ТЗ. Получить согласование от заказчика и уже после этого оценить работу по написанию функциональных требований.
Как говорится, слона надо есть по частям. И после каждого этапа у заказчика за его деньги будет готовый продукт, с которым он может продолжить работу с другим исполнителем.
Можно конечно, попробовать сразу сделать грубую оценку трудоемкости написания ТЗ, на основании первоначального анкетирования - сколько представителей заказчика надо опросить по функционалу приложения(и за какой срок каждый из них сможет передать свои знания, час/день/неделя/полмесяца/месяц), кто у заказчика будет принимать решения о согласовании противоречивых требований от разных представителей заказчика, сколько разных функциональных типов пользователей будет у приложения, сколько примерно функциональных единиц требований будет у каждого типа пользователей. Сколько примерно функциональных единиц будет среди серверных задач(которые выполняются независимо от действий пользователей). И тогда, если в процессе написания функциональных требований какие-то числа будут выше, чем в анкете, то это будет аргументированная позиция для пересмотра стоимости написания функциональных требований.
Если проект рос постепенно, то еще проще развивать framework. Начиная с пяти разработчиков уже точно надо делить на функциональную часть и инструментальную. Часто уже при меньшем количестве разработчиков.
Что касается генерации кода - видишь много тупого бойлерплейтного кода - начинаешь писать генерацию кода из метаданных, сгенерированный код прекрасно умеет жить вместе с написанным разработчиком, если его правильно организовать.
P.S. В большом проекте, где много разных разработчиков нужны стандарты кодирования, чтобы разные куски были написаны одинаково и разработчик мог легко разобраться в чужом коде. Чем больше стандартов, тем больше одинакового кода. Чем больше одинакового кода - тем больше кандидатов или на генерацию или на вынесениюе в инфраструктурную библиотеку.
Побывал на вашей странице присылайте резюме.
У вас такие технические требования к тех.лиду? Вы серьезно?
Опытный пользователь командной строки Linux, Bash
Практический опыт администрирования дистрибутивов Debian и Ubuntu.
Знание Astra Linux и его особенностей
Опыт настройки и администрирования серверов (Apache, Nginx, MySQL, PostgreSQL, Postfix и др.)
Глубокое понимание и опыт работы с ключевыми сервисами (AD DS, DNS, DHCP, DFS, VPN)
Опыт работы с системами виртуализации (KVM, VMware)
Телефония (PBX, настройка, траблшутинг)
Знание систем мониторинга (Zabbix, Nagios, Prometheus)
70 разработчиков фронт-приложения? Вы серьезно? 70 человек в состоянии написать 5-10 приложений, а не одно...
А если серьезно, надо выделить библиотеки(1-2-3-4), в которые вынести нефункциональный код. И нанять туда 4-5 сеньоров, такой команды достаточно, чтобы написать любую необходимую библиотеку.
Функциональные требования требования на фронте очень похожи, напиишите фреймворк, который на основе метаданных будет генерировать код. На это тоже хватит 4-5 сеньоров.
Ну а чтобы писать функционал на метаданных можно уже брать мидлов и даже джунов. На все про все хватит 10-20 человек.
Итого у вас команда в 20-30 человек вместо 70. Управлять ими гораздо проще, менеджеров надо меньше.
Каждому из core team платить конечно придется значительно больше, но в целом ФОТ получится уменьшить раза в полтора. И никакие микрофронты не нужны.
Вуаля!
Не благодарите.
P.S. Следующее приложение на готовом фреймворке можно написать уже гораздо быстрее... Правда современные эффективные менеджеры не имеют обыкновения думать о будущем :-(
А может вопрос неправильно поставлен? Может проблема в том, что команда кросс функциональная? Надо переразбиться в команды по профилю и проблем с код-ревью не будет?
Это у вас не умеют правильно ставить задачи, и декомпозировать большие задачи на средние с четким описанием интерфейсов взаимодействий. Если задачи грамотно поставлены, то разработчик может работать пару недель более-менее независимо. А если нужна коммуникация, то можно обсудить в мессенджере, в режиме сегодня спросил - завтра ответили. Но вопросы должны быть правильными (чтобы правильно задать вопрос надо знать 80% ответа)
А если задачи ставятся кое-как, то и надо обсуждать их каждые 3-4 часа. А это как делать - это я забыл обдумать. А то как делать - я не учел когда постановку писал....
Ничего это не другое... Как раз то самое.... Это ситуация когда здравый смысл заменяется идеями из книги, или от попов или еще от каких-то людей(сущностей).
Когда вместо того, чтобы принимать свои собственные решения, человек отдает принятие части решений на аутсорсинг другой сущности.
можно быть лидом на проекте, и без людей в подчинении. Если ты отвечаешь за все технические решения на проекте и контактируешь с нетехническим руководителем по задачам проекта. И задачи тебе ставятся в бизнес-разрезе, а как их реализовывать ты решаешь сам - ты несомненно лид.
я не знаю в каком бюрократическом мире живёт большинство комментирующих... может в банках или яндексах или на других галерах... А я большую часть жизни работал в небольших компаниях до 50 человек. и отпуска согласовывал по почте или в мессенджере. Заявление на отпуск писал за несколько дней до отпуска и оставлял нас подписью у бухгалтера или секретаря и подписанным его не видел. а иногда забывал написать до отпуска, и писал сразу после отпуска. И расценивать такой уклад как более человеческий, чем подписывать заявление за месяц или того пуще согласовывать график отпусков на год вперёд. Понятие график отпусков было в паре контор где я работал из более, чем десяти, в которых я работал.
а может с другого конца зайти и получить какое-нибудь не токсичное гражданство, хоть через фиктивный брак - а потом с ним уже работу искать за границей.
У меня знакомые и 4 дня в неделю работали и 2 и 2,5-3, правда обычно договаривались на своей работе, на которой уже известно было, что человек нормально работает. Так что проблема скорее всего, только при поиске новой работы, а на старой можно договориться.
Интересно, а токсичные люди воспринимают токсичность других? Или собственная токсичность защищает от проявления токсичности по отношению к себе?
Я за 20+ лет не встречал токсичных коллег. Встречал некомпетентных хоть и не часто, тупых изредка, интриганов пару раз.... Обманщиков среди тех кто нанимал несколько раз
Но в целом, на 80-90% атмосфера в компаниях где я работал была приятная и часто были умные люди среди коллег, с которыми было интересно общаться....
я не знаю, насколько легко найти работу. Но я знаю что потребовалось около полугода (правда не самых активных поисков), чтобы найти мидла на Котлине, который умеет программировать. и это на полную удаленку, с плавающим графиком, полностью по ТК. это на зп в 250к. так что не знаю, что там с дефицитом вакансий, а дефицит сотрудников. явно есть.... ну или наши Hr совсем не умеют людей искать. Про хбр и хх они знали и использовали.
не посылал резюме в 2023 году. но при этом 3-4 раза в неделю пишут с предложением рассмотреть вакансию. правда в 60% случаев вакансии не соответствуют моему резюме:-)