Цифра проверяется гораздо легче, чем текущие выборы, если все голосования открытые. И все голоса лежат в блокчейне, и я могу свой голос проверить в любой момент и любой человек может спросить у меня - а ты действительно так проголосовал.
Я не понимаю, что вы вообще хотите от банка? банки это не про написание хорошего софта, это про дурацкие правила, стандарты которые не подходят ни одному проекту, дублирование кода, усложнение архитектуры до невозможности, использование инструментов с которыми невозможно работать, но у нас корпоративный стандарт, отсутствие технического бекграунда у руководителей проектов и выше, ну и как Вишенка на торте - куча согласований и интриги среди менеджеров и топов....
Хорошая альтернатива собеседованию - экзамену для кандидатов от уровня сеньор-плюс и выше. Priduct owner рассказывает о проекте - кандидат спрашивает почему вы приняли те или иные решения, освещает возможные альтернативы, параллельно может рассказать о своем опыте релевантном проекту. Из вопросов, которые задаёт кандидат понять можно гораздо больше о его уровне, чем из его ответов на стандартные вопросы. И подготовить к такому собеседованию искусственно гораздо сложнее.... Потому что проекты в разных компаниях разные.
Чтобы защитить мелкие компании от крупных монополистов не надо создавать кучи и кучи антимонопольных законов. Надо начать с ограничения размера компании по стоимости. Например один миллиард долларов. И сразу решится куча проблем. И с людьми так же - тоже чтобы не больше одного миллиарда у человека.
Поздравляю вас, вы только, что описали принципы 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 часа. А это как делать - это я забыл обдумать. А то как делать - я не учел когда постановку писал....
Ничего это не другое... Как раз то самое.... Это ситуация когда здравый смысл заменяется идеями из книги, или от попов или еще от каких-то людей(сущностей).
Когда вместо того, чтобы принимать свои собственные решения, человек отдает принятие части решений на аутсорсинг другой сущности.
Брать деньги в долг под проценты под залог цифровых активов например.
Это уже давно обкатано в блокчейнах.
А сколько народу померло при них не важно?
Кажется мне, что если ты будешь в тех 5% населения, которые умрут - тебя развитие страны не сильно порадует.
Цифра проверяется гораздо легче, чем текущие выборы, если все голосования открытые. И все голоса лежат в блокчейне, и я могу свой голос проверить в любой момент и любой человек может спросить у меня - а ты действительно так проголосовал.
Так в телеграмме же можно за Тоны купить аккаунт и он будет привязан к твоему криптокошельку вместо телефона
Я не понимаю, что вы вообще хотите от банка? банки это не про написание хорошего софта, это про дурацкие правила, стандарты которые не подходят ни одному проекту, дублирование кода, усложнение архитектуры до невозможности, использование инструментов с которыми невозможно работать, но у нас корпоративный стандарт, отсутствие технического бекграунда у руководителей проектов и выше, ну и как Вишенка на торте - куча согласований и интриги среди менеджеров и топов....
Хорошая альтернатива собеседованию - экзамену для кандидатов от уровня сеньор-плюс и выше. Priduct owner рассказывает о проекте - кандидат спрашивает почему вы приняли те или иные решения, освещает возможные альтернативы, параллельно может рассказать о своем опыте релевантном проекту. Из вопросов, которые задаёт кандидат понять можно гораздо больше о его уровне, чем из его ответов на стандартные вопросы. И подготовить к такому собеседованию искусственно гораздо сложнее.... Потому что проекты в разных компаниях разные.
Чтобы защитить мелкие компании от крупных монополистов не надо создавать кучи и кучи антимонопольных законов. Надо начать с ограничения размера компании по стоимости. Например один миллиард долларов. И сразу решится куча проблем. И с людьми так же - тоже чтобы не больше одного миллиарда у человека.
Есть такое правило, когда тебе что-то объясняют - записывай. В следующий раз можно будет перечитать и не надо будет спрашивать.
Поздравляю вас, вы только, что описали принципы 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 часа. А это как делать - это я забыл обдумать. А то как делать - я не учел когда постановку писал....
Ничего это не другое... Как раз то самое.... Это ситуация когда здравый смысл заменяется идеями из книги, или от попов или еще от каких-то людей(сущностей).
Когда вместо того, чтобы принимать свои собственные решения, человек отдает принятие части решений на аутсорсинг другой сущности.