Далеко не всегда бизнес понимает, за что он платит. В синей банке, например, горе менеджеры придумали характеристику утилизация процессорного времени серверов. И если утилизация опускается ниже, ну например 80%(цифра условная), команде вставляются пистоны. Ну разработчики тоже не дураки - они вставляют в код запуски случайных задач с пустыми циклами, чтобы процессор работал и создавал утилизацию. Понимает бизнес за, что он платит?
У меня такое ощущение, что и по человеческим ресурсам есть такие же показатели по утилизации и "эффективные" менеджеры занимают своих сотрудников бессмысленной работой, лишь бы не получить пистоны за низкую утилизацию. Ну и чтобы сотрудников не забрали в другой департамент. Ведь, чем больше у менеджера сотрудников, тем он круче.
не только компании хотят, чтобы один человек закрывал 2-4 роли. Я, например, сам хочу закрывать несколько ролей, иначе мне неинтересно. и коленом быть неинтересно, и аналитиком или архитектором неинтересно, потому что они в основном пишут документацию. Я хочу придумывать полное решение бизнес-план и программировать его основу, а части попроще передавать мидлам и/или Джуниора.
И для бизнеса это сильно выгоднее, потому что когда каждую роль закрывает один человек - в коммуникациях между ними всегда что-нибудь теряется... да и по времени выгоднее, когда один человек придумывает решение и руководит его воплощением в жизнь. не теряется время на многочисленные болтологии...
Цифра проверяется гораздо легче, чем текущие выборы, если все голосования открытые. И все голоса лежат в блокчейне, и я могу свой голос проверить в любой момент и любой человек может спросить у меня - а ты действительно так проголосовал.
Я не понимаю, что вы вообще хотите от банка? банки это не про написание хорошего софта, это про дурацкие правила, стандарты которые не подходят ни одному проекту, дублирование кода, усложнение архитектуры до невозможности, использование инструментов с которыми невозможно работать, но у нас корпоративный стандарт, отсутствие технического бекграунда у руководителей проектов и выше, ну и как Вишенка на торте - куча согласований и интриги среди менеджеров и топов....
Хорошая альтернатива собеседованию - экзамену для кандидатов от уровня сеньор-плюс и выше. 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%(цифра условная), команде вставляются пистоны. Ну разработчики тоже не дураки - они вставляют в код запуски случайных задач с пустыми циклами, чтобы процессор работал и создавал утилизацию. Понимает бизнес за, что он платит?
У меня такое ощущение, что и по человеческим ресурсам есть такие же показатели по утилизации и "эффективные" менеджеры занимают своих сотрудников бессмысленной работой, лишь бы не получить пистоны за низкую утилизацию. Ну и чтобы сотрудников не забрали в другой департамент. Ведь, чем больше у менеджера сотрудников, тем он круче.
не только компании хотят, чтобы один человек закрывал 2-4 роли. Я, например, сам хочу закрывать несколько ролей, иначе мне неинтересно. и коленом быть неинтересно, и аналитиком или архитектором неинтересно, потому что они в основном пишут документацию. Я хочу придумывать полное решение бизнес-план и программировать его основу, а части попроще передавать мидлам и/или Джуниора.
И для бизнеса это сильно выгоднее, потому что когда каждую роль закрывает один человек - в коммуникациях между ними всегда что-нибудь теряется... да и по времени выгоднее, когда один человек придумывает решение и руководит его воплощением в жизнь. не теряется время на многочисленные болтологии...
Брать деньги в долг под проценты под залог цифровых активов например.
Это уже давно обкатано в блокчейнах.
А сколько народу померло при них не важно?
Кажется мне, что если ты будешь в тех 5% населения, которые умрут - тебя развитие страны не сильно порадует.
Цифра проверяется гораздо легче, чем текущие выборы, если все голосования открытые. И все голоса лежат в блокчейне, и я могу свой голос проверить в любой момент и любой человек может спросить у меня - а ты действительно так проголосовал.
Так в телеграмме же можно за Тоны купить аккаунт и он будет привязан к твоему криптокошельку вместо телефона
Я не понимаю, что вы вообще хотите от банка? банки это не про написание хорошего софта, это про дурацкие правила, стандарты которые не подходят ни одному проекту, дублирование кода, усложнение архитектуры до невозможности, использование инструментов с которыми невозможно работать, но у нас корпоративный стандарт, отсутствие технического бекграунда у руководителей проектов и выше, ну и как Вишенка на торте - куча согласований и интриги среди менеджеров и топов....
Хорошая альтернатива собеседованию - экзамену для кандидатов от уровня сеньор-плюс и выше. Priduct owner рассказывает о проекте - кандидат спрашивает почему вы приняли те или иные решения, освещает возможные альтернативы, параллельно может рассказать о своем опыте релевантном проекту. Из вопросов, которые задаёт кандидат понять можно гораздо больше о его уровне, чем из его ответов на стандартные вопросы. И подготовить к такому собеседованию искусственно гораздо сложнее.... Потому что проекты в разных компаниях разные.
Чтобы защитить мелкие компании от крупных монополистов не надо создавать кучи и кучи антимонопольных законов. Надо начать с ограничения размера компании по стоимости. Например один миллиард долларов. И сразу решится куча проблем. И с людьми так же - тоже чтобы не больше одного миллиарда у человека.
Есть такое правило, когда тебе что-то объясняют - записывай. В следующий раз можно будет перечитать и не надо будет спрашивать.
Поздравляю вас, вы только, что описали принципы planing poker и как вычислять velocity команды. У меня вы свое время ушло 8-10 двухнедельных спринтера, перед тем как velocity команд стабилизировалось.
Это классический случай, когда сроки спрашивать не надо с разработчиков. В таких случаях сроки надо ставить. А разработчики должны их выполнять, жертвуя или качеством или овертаймами, за которые должна платить фирма... Ну а потом отпуска-отгулы и т.д. с одной стороны и тех.долг с другой. Отпуска и отгулы, чтобы компенсировать психологический перегруз it команды.
А как простите 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. Следующее приложение на готовом фреймворке можно написать уже гораздо быстрее... Правда современные эффективные менеджеры не имеют обыкновения думать о будущем :-(
А может вопрос неправильно поставлен? Может проблема в том, что команда кросс функциональная? Надо переразбиться в команды по профилю и проблем с код-ревью не будет?