Разработка и внедрение в новой реальности: можете не меняться. Выживание не является обязанностью

13.09.24

Управление проектом - Agile

Тенденции последнего времени заставляют пересматривать привычные инструменты, менять подходы, подстраиваться под рынок труда. Расскажем об импортозамещении инструментария внедренцев, отличиях Agile от почасовки и рисках дефицита специалистов 1С.

Тема доклада – разработка и внедрение в новой реальности. Когда мы согласовали эту тему, я наивно полагал, что новая реальность уже понятна и неопределенность снизилась. Но как говорится в известном анекдоте: «Только показалось, что хуже уже быть не может, и снизу постучали». Тем не менее я думаю, что доклад остается актуальным, и те техники, приемы, подходы, о которых пойдет речь, будут полезны.

 

Все, что я буду рассказывать, исходит из практического опыта. Это не просто теоретические рекомендации или методы, прочитанные в книгах, хотя я действительно прочитал о них в книгах. Это то, что было реально опробовано в работе нашего подразделения БИТ:ERP в компании «Первый БИТ»:

  • Мы занимаемся внедрением 1С:ERP в торгово-производственных компаниях. Среднее количество пользователей на наших проектах – 1000 человек. Минимальный проект за последние несколько лет насчитывал 100 пользователей, самый крупный – в районе 4000.

  • Есть продуктовая разработка – как на платформе 1С, так и на Python, Java, C++.

  • Некоторые знают нас по активности в части open-source движения – наши разработки можно увидеть на GitHub. Например, PinkRabbitMQ – компонента для обмена с RabbitMQ.

  • И у нас относительно новое направление – это промышленная автоматизация, Industrial Internet of Things (IIoT), промышленный интернет вещей. Это сборка шкафов управления, программирование логических контроллеров, SCADA-системы и так далее.

 

На слайде – цитата Виктора Франкла. Это австрийский психиатр, философ, психолог, невролог, практик. В юности он был узником нацистского концлагеря, и на основе своего опыта написал множество трудов. Его книга «Скажи жизни: Да!» произвела на меня сильное впечатление. Она переведена на русский язык, и это, пожалуй, то, что я рекомендовал бы прочесть в первую очередь.

Слова на слайде отражают наблюдения Виктора Франкла о жизни в концлагере. Я считаю, что этот же подход нужно использовать и в текущих обстоятельствах, в текущей реальности:

«Первыми ломались те, кто верил, что скоро все закончится. За ними идут те, кто не верил, что это когда-нибудь закончится. Выжили те, кто сосредоточился на своих действиях, без ожиданий того, что может произойти или не случиться».

В нашем случае это значит, что лучше сконцентрироваться не на обсуждении новостей и просмотре новостных лент Telegram-каналов. На это мы повлиять не можем, а время, силы, энергию и внимание это у нас отжирает.

Нужно сконцентрироваться на том, на что мы можем повлиять – на нашей работе и том, что мы делаем. Поэтому дальше доклад будет про подход к новой реальности в рамках того решения, которое предложил Виктор Франкл.

 

Риски

 

Изначально я формулировал на этом слайде факты новой реальности. Сейчас слайд называется «Риски», потому что неопределенность повысилась:

  • Понятное дело, что санкции никуда не денутся, но если раньше у нас импортозамещение позиционировалось в виде западозамещения, то в ближайшее время оно действительно может стать импортозамещением – в силу того, что оборудование из Азии тоже будет использовать проблемно.

  • Обострение дефицита специалистов 1С – это риск, который сейчас есть, а как дальше будет развиваться ситуация – непонятно.

  • И падение спроса на автоматизацию. Казалось бы, этот риск исключает предыдущий, но есть опасения, что для нас актуальны оба этих риска. Чуть позже я объясню, почему.

  • И расширение государственного вмешательства в экономику – это тоже риск, потому что мы привыкли работать в одной среде, а она может оказаться другой. Сейчас степень государственного вмешательства в экономику высокая, остается примерно на том же уровне, что и раньше. И пока предпосылок для ее расширения не видно – мы как работали, так и работаем. Но это не перестает быть риском.

 

Импортозамещение инструментария внедренцев

 

Теперь по конкретным инструментам. Первое, что мы сделали у себя в подразделении для работы с рисками – это начали переход с Windows на Linux.

На рынке часто встречается ситуация, когда интегратор переводит клиентов с Windows на Linux, при этом сами разработчики 1С, консультанты, внедренцы, администраторы цинично продолжают работать на Windows – применяют новые практики к заказчику, не применяя их к себе.

В принципе, это нормальный подход, потому что перевести на Linux сервер 1С и перевести на Linux пользовательское рабочее место, особенно рабочее место разработчика – это разные вещи.

Но мы решили начать с себя и действительно перевели всех сотрудников нашего подразделения на Linux. Сейчас все рабочие станции разработчиков работают под Linux. И большинство серверов тоже под Linux.

На слайде – реальный скриншот, как выглядит конфигуратор на Linux. Если коротко, по итогам всех страданий, выполнения инструкций, подгрузки виндовских шрифтов и так далее – он выглядит практически так же.

 

А это – скриншот Visual Studio Code, в котором у нас редактируется автотесты на Gherkin. Мы используем Vanessa Automation, поэтому нам было важно, чтобы с редактором кода тоже было удобно работать.

У нас было три этапа перехода на Linux:

  • До начала перехода казалось, что Linux – это страшно и непонятно. Все привыкли к Windows, никто не хотел переходить. Под «никто» я имею в виду разработчиков.

  • Потом, когда причина и необходимость перехода стала очевидна, мы начали искать решения – стали анализировать, насколько сложно будет перейти.

  • А когда мы все проанализировали, возникло другое ощущение – что перейти будет совсем легко, все произойдет чуть ли не по щелчку пальцев. Правда, это оказалось не совсем так. В итоге сложность перехода оказалась где-то посередине между «это очень сложно, на грани невозможного» до «все очень просто, за один день перейдем».

Мы посмотрели, какие основные приложения у разработчика 1С:

  • Конфигуратор. Я думаю, что примерно 60% рабочего времени у разработчика так или иначе открыт конфигуратор, он в нем работает.

  • Браузер – чтобы что-то гуглить, читать.

  • Редактор кода, чтобы редактировать, просматривать сценарии – у нас это Visual Studio Code.

  • Разумеется, в режиме предприятия, чтобы смотреть, что я сделано, и пользоваться DevOps-сервисами.

И все.

А поскольку у нас полностью облачная инфраструктура, все работают через удаленный рабочий стол, нам показалось, что если вдруг какое-то приложение не работает под Linux на удаленном рабочем столе, – разработчик может запускать его на своем личном компьютере.

 

Чтобы говорить о нашем опыте более практически, не ограничиваясь рекомендацией: «Переходите все на Linux!», я подготовил список того, что нам было бы полезно знать перед началом перехода.

  • Во-первых, задача организации на Linux рабочего места для пользователя, который будет интерактивно работать с системой через пользовательский интерфейс, и задача организации на Linux администрирования серверных приложений (для сервера 1С:Предприятия, сервера баз данных, брокера сообщений RabbitMQ и т.д.) – это разные задачи. Людей, умеющих организовать рабочее место на Linux для пользователя, гораздо меньше, чем тех людей, которые хорошо умеют администрировать серверы на Linux.

  • Во-вторых, работа конфигуратора 1С под Linux имеет ряд особенностей. Часть из этих особенностей хорошо описана в документации – любой человек, который начинает работать в Linux, достаточно быстро разберется со шрифтами и поймет, что нужно сделать, чтобы это нормально работало. Важно, чтобы когда вы запустите 1С:Конфигуратор и убедитесь, что он в принципе работает под Linux, этим дело не закончится. В нашей практике возник вопрос стабильности работы и подвисания. Причем подвисание нерегулярное и даже недостаточно частое для того, чтобы администратор, который все это настраивает, мог это обнаружить. Это обнаруживается в течение рабочего дня – за 8 часов разработчик с этим сталкивается. Такие плавающие проблемы доставляют много нервов, и тратится много времени. При этом надо помнить о том, что пока опыт работы разработчиков 1С на Linux еще не такой большой. На форумах, в том числе партнерском, не так много релевантных тем. И когда ты гуглишь проблему, возникшую при работе конфигуратора 1С на Linux, высока вероятность, что никакого решения не найдешь. Тем не менее у нас все получилось – все это работает.

  • Следующая проблема, которая для нас тоже стала неожиданной – это то, что ряд типовых конфигураций 1С совсем не рассчитаны на Linux. Самый болезненный для нас пример – это сборщик мобильных конфигураций. Мы разрабатываем тиражное решения БИТ:MDT для терминалов сбора данных, и наш программный продукт в пике разработки релизился до сотни сборок в день. При этом фирма «1С» говорит, что сборщик не будет поддерживать Linux, и правильнее делать сборку через веб-сервис. Но веб-сервис и сборщик решают разные задачи. И сто раз зайти вручную, собрать, подождать и дальше продолжить цикл тестирования – это явно не то решение, которое нас устроит. Поэтому часть серверов у нас пока что остаются на Windows.

  • Ну и помните о том, что для Linux мощностей потребуется больше – в первую очередь, оперативной памяти. Но если вы уже работаете в облаке, и потребляете облачные ресурсы, для вас это серьезной проблемой не будет, потому что виртуальная память сейчас относительно дешевая.

 

Миграция с Atlassian Jira на Yandex Tracker

 

 

Дальше – миграция с Atlassian.

До февраля 2022 года мы использовали облачные продукты Atlassian для управления процессами и документацией – это Atlassian Jira, Atlassian Confluence и Jira Service Desk. Понятное дело, что с 24 февраля достаточно резко стало невозможно им пользоваться с точки зрения оплаты. А в последнее время и официально, даже если ты решил вопрос с оплатой, то все равно, скорее всего, пользоваться не сможешь.

На скриншоте пример Scrum-доски, спринт конкретной команды, как это выглядит в Yandex Tracker. Сразу скажу, что мы посмотрели достаточно много продуктов, и Yandex Tracker оказался практически единственным, который нам подошел.

У нас были специфичные требования – к примеру, у нас было требование, что мы не хотим сами хостить систему. Возможно, если вы готовы развернуть сервис на своих серверах администрировать его 24/7, 365 дней в году, наверное, у вас будет какой-то другой выбор. Мы этот выбор не рассматривали, поэтому выбрали Yandex Tracker, потому что больше ничего не нашли из того, что там подходит.

Из минусов – понятное дело, что это далеко не Jira, но все основные функции там есть, и работать действительно можно и удобно. Там есть:

  • бэклог;

  • канбан-доски;

  • все необходимые поля;

  • интеграция с Yandex Wiki.

Но там нет интеграции с Git – она формально есть, галочка стоит, но исходите из того, что интеграции там нет. Те, кто пользуется Git, может попробовать и поймет, о чем я.

Еще неожиданно понравилось, что там верная терминология. Тех, кто заморачивается с продуктовой разработкой, может смущать тот факт, что в Jira пространство для задач называется «проектом», при том, что мы работаем над продуктом. А Yandex Tracker развивался как Service Desk, поэтому у него термин «очередь». Этот термин тоже не очень удачный, но гораздо удачнее, чем «проект», с моей точки зрения, потому что нет никакой путаницы с продуктовым подходом.

 

Миграция с Atlassian Confluence на Yandex Wiki

 

 

С Yandex Wiki ситуация обратная. Если Yandex Tracker у нас хорошо зашел – им без проблем пользуются и наши разработчики, и сотрудники заказчика. То с Yandex Wiki возникли проблемы. Он удобен только для тех, кто знает Markdown, и любит на нем писать. Для всех остальных пользователей, кто привык работать в Word или в Confluence, в Yandex Wiki будет сложно. Имейте это в виду.

Тем не менее на Yandex Wiki мы тоже перешли, во многом потому, что у нас нет больших требований к Wiki-системе. Мы делаем упор не на мертвую документацию, существующую отдельно от кода где-то там в Wiki. Мы при любой возможности предпочитаем написать сценарий тестирования в виде автотеста, который будет каждый раз обновляться и прогоняться при мерже в мастер.

По лайфхакам о том, на что мы успели перейти за последнее время – я все, что мог, рассказал.

 

Уровень зарплаты vs Число специалистов

 

Теперь расскажу о дефиците специалистов 1С.

 

Многие знают картинку, которая иллюстрирует главный тезис экономической теории – чем больше спрос, тем больше предложений. Но это – наивная экономическая теория, вернее, представление об экономической теории от тех людей, которые не читали экономическую литературу.

 

А те, кто читал экономическую литературу, знают, что специалисты по 1С не могут взяться откуда-то мгновенно, их количество на рынке условно постоянное и может увеличиваться по мере роста зарплаты только в долгосрочной перспективе. А в краткосрочной перспективе зависимость между спросом и предложением выглядит, как на этом слайде.

 

Но по нашему опыту зависимость спроса и предложения на рынке труда 1С-ников выглядит еще хуже – отсюда и дефицит специалистов.

Мы наблюдаем тенденцию: чем выше зарплату готовы платить компании – тем меньше специалистов на рынке.

Причем на предыдущем слайде была правда: количество специалистов 1С действительно может не меняться. Но если взять из них тех, кто действительно готов работать, их число сокращается.

Я не беру сейчас тимлидов, не беру сеньоров, я беру середнячков, на которых держится любая продуктовая разработка. Без них ни одна задача, по сути, не будет выполнена – тимлид не может сделать всё в одиночку.

Итого, середнячок. У него работа ассоциируется с зарплатой – чтобы получить зарплату, нужно поработать. Но как только он достигает комфортного для него уровня оплаты, он старается меньше работать, а большую часть времени посвящает своим увлечениям и хобби.

Если у тимлида хобби – это работа, он без проблем отправляет запросы на мерж в мастер в субботу или воскресенье, то от середнячка, конечно, такого не видишь. Понятное дело, что в свободное время человек отдыхает, занимается теми делами, которые его интересуют.

Это приводит к тому, что человек, который раньше вкалывал на проектах внедрения ERP, идет к заказчику на спокойную работу с меньшей загрузкой. И там получает те же деньги, которые получал раньше, но много работал.

Отсюда как раз утверждение, что падение спроса на автоматизацию и дефицит специалистов – не обязательно взаимоисключающие вещи, они могут совпасть.

 

ТОП-4 вопроса по Agile

 

Теперь дам ответы на вопросы, на которые меня попросили ответить в докладе организаторы.

 

Вопрос №1. Что выбрать: каскад или agile?

 

Первый вопрос – что выбрать в рамках проекта: каскад или agile?

Я взял на себя обязательство ответить в докладе на этот вопрос, но шансов быть услышанным и понятым у меня мало, потому что я отвечал на него много раз.

В 2017-м году на конференции Инфостарта я рассказывал, как выбирать Agile, и почему мы выбрали на конкретном проекте Agile.

 

Потом пытался ответить примерно на тот же самый вопрос в 2018 году.

 

И в 2019 году было примерно все то же самое.

 

В течение многих лет я пытался ответить на этот вопрос, используя ответы из книги Джеффа Сазерленда, которая называется «Искусство делать вдвое больше работы за вдвое меньшее время» или в русском варианте «Scrum: Революционный метод управления проектами». Книга реально интересная – если не читали, обязательно прочитайте.

Но если мы говорим про компанию и про команду, которая задает вопрос «Каскад или Agile?», эта книга особо не поможет в выборе, потому что эта книга про тех, кто такой вопрос не задает.

 

Если у вас вопрос: «Что выбрать: каскад или Agile?», то гораздо более правильный вопрос, который вам надо задать и единственный, это: «Что произойдет, если задача не будет решена в поставленный срок?» Ответ на этот вопрос вам нужно просто продиагностировать:

  • Если задача такова, что ее нельзя зафейлить, а последствиями срыва дедлайна будет «полярный лис», причем в жестких проявлениях (например, компания разорится, всех уволят и так далее) – однозначно ответ Agile, других вариантов нет.

  • А если проект задержится, задачи профакапятся, но на самом деле ничего страшного не произойдет – тогда каскад. В Agile даже лезть не стоит. Честно, это глупо. Ничем хорошим это не закончится.

Могу объяснить почему.

  • Agile – не гарантия успеха. Не гарантия, что работа будет сделана экономно. Даже не гарантия, что она будет сделана быстро.
    Но если вы делаете проект по Agile, вы заранее узнаете о том, что он «не взлетит», и система не запустится. Это значит, что вы можете что-то с этим сделать. Если у вас задача, которую вы не имеете права зафейлить, вы, разумеется, будете пытаться сделать так, чтобы ее не зафейлить. Именно поэтому вы можете сменить команду внедрения, вы можете оказать какое-то воздействие на ключевых пользователей. Вы можете много чего сделать. В крайнем случае, если что-то пойдет совсем не так, вы можете резюме на HeadHunter выложить.

  • А если мы говорим про каскад, то о фейле вы обычно узнаете внезапно – после большого взрыва, когда уже поздно что-то менять.

Важное ограничение: это утверждение применимо только тогда, когда вы не купили почасовку под брендом Agile. Я имею в виду «купили» в широком смысле – т.к. вы могли купить, условно, внутреннего подрядчика.

 

Вопрос №2. Чем отличается Agile от «почасовки»?

 

Отсюда второй вопрос: а чем отличается Agile от «почасовки»?

Если задать этот вопрос рядовым членам команды исполнителя, в большинстве случаев они честно скажут: «Да ничем не отличается, просто такой модный термин – Agile. Scrum проще продавать, поэтому мы раньше делали “почасовку”, сейчас мы делаем Scrum, а на самом деле разницы какой нет». А разница большая.

  • Если выбирать между «почасовкой» и каскадом, я бы выбрал каскад – там хотя бы какие-то шансы у вас появляются.

  • Шансы, конечно, есть и в «почасовке», но их меньше. Поэтому будьте аккуратны.

Чтобы разобраться в том, работает ваш подрядчик по Agile или нет, задавайте вопросы и оценивайте по Станиславскому «верю-не верю». Если специалисты подрядчика действительно работают по Agile, они смогут ответить на вопрос таким образом, чтобы вы поверили, что они действительно понимают, о чем говорят. Даже если вы не поймете какие-то детали.

Коротко расскажу про ключевые отличия Agile-подхода от «почасовки»:

  1. Это мотивация команды. В Agile-подходе у команды нет мотивации закрыть больше часов – в документах по схеме мотивации подрядчика не должно быть ничего про часы.

  2. У вас с подрядчиком нет торга по поводу трудоемкости конкретной задачи. Учет рабочего времени ведется – если он не ведется, это бардак, не имеющий никакого отношения к Agile, даже если кто-то говорит обратное. Но учет времени используется не для торга с заказчиком, не для подтверждения выполненных работ, а только для того, чтобы повысить эффективность. Просто потому, что конкретный лог часов помогает команде на ретроспективе понять, на чем она продолбалась, и что нужно изменить, чтобы в следующий раз быть эффективнее

  3. Lean-мышление. Это борьба с потерями времени в производстве, избавление от незавершенки и так далее. Там достаточно много всего. Я уже рассказывал на конференции Инфостарта об этом.

  4. Эмпирический подход.

  5. Современные инженерные практики.

 

Вопрос №3. Как может быть в Agile-проекте фиксированный бюджет?

 

Третий вопрос – как в Agile-проекте может быть фиксированный бюджет.

Даю короткий ответ: в Agile-проекте бюджет фиксирован по определению, поэтому он только такой может быть. Если у вас не фиксированный бюджет, у вас не Agile-проект. Это определение.

 

На слайде – тезисно перечислены отличия подходов Agile и каскада относительно бюджета:

  • Agile – это про бизнес-ценность про outcome.

  • А каскад – это про артефакты, про результаты, про output.

Именно поэтому в Agile неважно, что конкретно мы делаем, важнее принести бизнес-ценность. А в каскаде – наоборот.

 

Вопрос №4. Продукт vs Проект. Когда продуктовый подход не подходит?

 

Ну и последний, четвертый вопрос: Продуктовый подход или проектный подход: когда продуктовый подход не подходит?

На него у меня короткий ответ:

  • Если вам не подходит Agile, тогда и продуктовый подход вам не подойдет.

  • И обратное утверждение тоже верно.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2022 Saint Petersburg.

 

Приглашаем на конференции Инфостарта 2025 года

INFOSTART TEAMLEAD EVENT

Не только для разработчиков, но и для руководителей отделов разработки, тимлидов и ИТ-директоров.
Место: Москва
Даты: 24-25 февраля 2025 г.

Подробнее

INFOSTART A&PM EVENT (Анализ & Управление проектами)

Практическая конференция для аналитиков и руководителей проектов 1С.
Место: Санкт-Петербург
Даты: 29-31 мая 2025 г.

Подробнее


См. также

Анализ бизнес-процессов Внедрение изменений Бесплатно (free)

Во втором выпуске третьего сезона подкаста Радио “Аналитик“ обсудили, как на этапе собеседования определить, что в компании незрелые процессы, как действовать, если мы выбрали работать в такой компании, и что необходимо делать, чтобы выстроить процессы.

23.09.2024    270    0    Radio_Analyst    1    

3

Инструменты управления проектом Внедрение изменений Бесплатно (free)

Кризисная ситуация характерна тем, что привычные средства, методы и окружение меняются. Но эти изменения приносят с собой не только потери, но и новые возможности. Об опыте принятия решений в критических точках проекта расскажем в статье.

12.09.2024    295    0    ermakovalekseyv    0    

2

Внедрение изменений Бесплатно (free)

Любой проект внедрения системы управления и учета – это проект организационных изменений. Меняются процессы, роли, требования к сотрудникам компании, распределение задач. Неавтоматизированные ранее участки подлежат автоматизации. Работа людей систематизируется и часто перестраивается. Как следствие, успех проекта в целом существенно зависит от того, какие изменения в организации должны произойти, а какие не произошли. И насколько сотрудники компании-заказчика этим изменениям помогали/сопротивлялись. Расскажем о том, как выявить сопротивление и сгладить недоверие пользователей в совместной работе на проекте.

11.09.2024    557    0    cybrat    0    

2

Внедрение изменений Бесплатно (free)

Когда при внедрении систем 1С всплывает слово «ГОСТ» – практически всегда речь идёт о документе «Техническое задание». И у большинства внедренцев падает настроение, как только им говорят, что надо «написать ТЗ по ГОСТу». Но опытные кулинары знают, как готовить это блюдо так, чтобы оно оставило после себя приятное послевкусие, а не горькое разочарование. О собственных рецептах приготовления документации по ГОСТу пойдет речь в статье.

21.08.2024    2416    52    Laya    3    

20

Внедрение изменений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Проект по переходу SAP на 1С – это не только перенос в 1С бизнес-процессов, которые ранее отражались в SAP. Системы отличаются кардинально – и подходом к внедрению, и работой в системе, и готовыми функциональными блоками, и интерфейсами. Расскажем о том, какие подводные камни ждут внедренцев на проектах перехода с SAP на 1С.

19.08.2024    9368    0    vladshelshel    7    

4

Оптимизация бизнес-процессов Взгляд со стороны Заказчика Внедрение изменений Платформа 1С v8.3 Бесплатно (free)

Проекты перехода с SAP на 1С неизбежно связаны с различиями в терминологии, изменением привычных подходов, перестройке и унификации бизнес-процессов. О том, как найти ключи к успеху реализации такого проекта на реальном примере перехода с SAP на 1С, пойдет речь в статье.

13.08.2024    833    0    avermakov1986    5    

4

Внедрение изменений Бесплатно (free)

Зачастую, если мы пытаемся оценить прямой эффект от внедрения систем 1С, он отрицательный, потому что на внедрение и поддержку ИС надо тратить деньги (часто – очень большие), а даёт она на выходе только информацию. Однако, есть и косвенный эффект, который может быть значительно более существенным для бизнеса. Сама по себе информация о том, что происходит в компании, ничего не экономит. Экономия достигается за счёт управленческих решений и инструментов управления, которые строятся на получаемом поле данных. Расскажем о том, как с помощью автоматизации получить информацию для принятия решений и повысить эффективность бизнеса.

30.07.2024    869    0    MichaelMontrel    2    

6

Внедрение изменений Бесплатно (free)

Зимой 2024 года в нашей компании произошла реорганизация: раньше в группу входили два юрлица, одно решили закрыть и всех работников перевести в другое с сохранением всех должностей, окладов и прочей бухгалтерии. Рассказываем, как мы это сделали. 

16.07.2024    1226    0    Neti    2    

-1
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. RustIG 1728 14.09.24 11:38 Сейчас в теме
100 или 4000 пользователей - не имеет значения, главное сколько бизнес-процессов выстроено, автоматизировано. Потом БП масштабируются на нужное кол-во сотрудников.
2. RustIG 1728 14.09.24 11:47 Сейчас в теме
В докладе обо всем понемногу. Нет общей канвы.
Была жира, стал я-трекер, печально, что на я-трекер обратили внимание по остаточному принципу, а не исходя из качественных или экономических показателей. При ваших доходах свой трекер можно разработать, бит-трекер назовите.
3. RustIG 1728 14.09.24 11:56 Сейчас в теме
Франкла зачем в статью вписали? Уточните смысл, пожалуйста.

Про выходные сотрудников вывод неверный сделали - связали с достижением уровня зарплаты и уровня комфорта...Понимание у вас людей пока на начальном уровне.

Про сборщик моб. приложений на линуксе, спасибо что поделились. Тут уж не поспоришь, когда делитесь техническим опытом...
Оставьте свое сообщение