Ускорение4X: история появления

30.07.18

Саморазвитие

Краткая история появления методики #Ускорение4X

Читатели публикаций про #Ускорение4X убедили меня, что я не прав, сразу пересказывая методику, и ничего не поведав об истории ее возникновения. Исправляюсь.

Нам удалось ускорить разработку в команде в 4 раза в течение 5 месяцев, с перерывами. Потом нам удалось несколько систематизировать наш путь, и применить не только в разработке. Развивать методику мы продолжаем и поныне (правда, нас стало меньше).

История эта случилась несколько лет назад, в ИТ-отделе не очень большого производственного предприятия. Нас там было пятеро, включая меня, программировали мы на 1С. Скептикам сразу скажу, что язык и среда программирования роли не играют — сейчас я ровно тот же опыт повторяю на javascript.

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

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

Классический скрам


Выбор пал на скрам — давно про него слышали, вроде он делает жизнь лучше. Почитали руководства в интернете, практики и опыт коллег, и сделали все так, как написано.

Доска, стикеры, митинги, скрам-мастер и т.д. Освоив в первый же день методику покера планирования, пересчитали ретроспективно несколько недель, получили цифру — 4.2 балла в день на человека (далее все оценки будут приведены к баллам на человека в день, нам так показалось честнее считать).

В первую же неделю скрама, на волне энтузиазма, мы сделали 7 баллов. Во вторую — 10. В третью — 13.

Вау! — думали мы! В два раза быстрее! Гениально! Спасибо, скрам!
 

Привыкание


Но, потом скорость начала падать. Энтузиазм прошел, стикеры вешать стало лень, но мы держались. Понимали, что это нормально — устать и опустить руки. Надо просто привыкнуть.

Взяли себя в руки, перетерпели, заставляя себя, и — привыкли. Это перестало быть проблемой.

Правда, скорость больше не росла — 13 баллов третьей недели так и остались максимумом. В среднем у нас получалось сделать около 8 баллов, иногда чуть больше, иногда чуть меньше.

Сначала это казалось магией, потом стало привычкой, и трудностей не вызывало. Но есть в этом что-то необычное, все равно — простые методы, простой алгоритм, и в два раза больше результата. Без переработок, без увеличения штата, без инфляции оценок (даже с дефляцией).

Итого, весь этот первый этап продлился 3 месяца.
 

Перерыв


Потом случился перерыв — я с головой ушел в проект, который был вне ИТ-отдела, и не мог принимать участия в скраме. Ребята разъехались по разным офисам, и начались проблемы с общей доской для задач. Скрам они, тем не менее, как могли, поддерживали, потому что к нему привыкли.

Я в это время занимался стратегическим развитием предприятия, с применение самых разных методик, в том числе скрама. И как-то так получилось, что попалась мне на глаза распродажа книг от МИФа, и там был скрам — та самая красная книга Джеффа Сазерленда.

Прочтение книги, после трехмесячного использования скрама по инструкциям интернета, было настоящим озарением. То, что написано в инструкциях, в том числе scrum guide — банальная пошлость по сравнению со смыслом книги и, соответственно, самого скрама.

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

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

Второй этап


Раз мы теперь знали, что законов скрама не существует, мы поменяли их в первый же день. Выкинули доску, отменили утренние митинги, ретроспективы, проекты — почти все. Оставили только покер планирования, измерение скорости команды в баллах, роли владельца продукта и скрам-мастера.

Доску заменили простейшей автоматизацией, митинги — постоянным наблюдением за процессом, ретроспективы — постоянным изменением процесса.

Второй этап продолжался 2 месяца, за это время мы наработали и проверили на себе примерно 40 практик, методик, фишек и приемов, которые в совокупности дали нам ускорение в 4 раза. Часть из этих практик мы придумали раньше, до скрама вообще, но систематически не применяли, т.к. не видели в этом смысла.

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

За два месяца мы вышли на устойчивую скорость 17.3 балла, что в 4.11 раза больше первой цифры, которая была до скрама. Оттуда и пошло #Ускорение4X.
 

Новая компания


Через некоторое время я ушел из той компании, и у меня было подозрение, что ускорение было вызвано стечением обстоятельств — ну, мало ли, повезло, или мы чего-то напутали в расчетах.

Я попал в другую компанию, где разрабатывают и внедряют решения на javascript. Там я и продолжил свои исследования эффективности.

Там тоже встречается 1С, поэтому моя эффективность не упала до нуля. Но там пришлось разбираться в javascript, а еще решать задачи управления внешними проектами, менеджмента и маркетинга — отличное поле для экспериментов.

Что в итоге (промежуточном)? Сейчас, на момент публикации, моя средняя скорость составляет 20 баллов — это уже растянутое ускорение в 5 раз. Для меня очевидно, что я могу прибавить еще минимум вдвое, когда наконец проникнусь js до нормального состояния.

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

В этой публикации я перечислю основные практики с кратким описанием, чтобы было понятно, о чем пойдет речь во всем сериале.
 

Основные практики


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

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

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

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

Мы ранее предполагали, что расчет сроков можно автоматизировать, и даже сделали это — у нас была очень крутая система планирования, одновременно по ASAP и ALAP, с учетом всего, чего только можно. Ее мы не выкинули, а оставили — для планирования производства, закупок и кассовых разрывов.

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

Цель каждого была учтена, и появилась итоговая цель — «работать на будущего работодателя», или проще говоря — на свой опыт. На то, что останется с тобой после увольнения.

И жить стало значительно интереснее, т.к. каждый из парней находил для себя в каждом дне что-то полезное.

Очень быстро мы поняли влияние абстрактных решений на ускорение. Если работали в 1С, знаете, что там с абстрактными решениями полная задница, и чем дальше, тем хуже — спасибо вендору. Абстрактные решения снимали с нас целые пласты задач, экономя массу времени. За 2 месяца мы создали примерно 10 абстрактных решений (до этого — 20 за три года).

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

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

Потом мы заметили, что самые слабые члены команды теряют время на том, что раздумывают — как оптимальнее сделать? Вроде правильное желание, но на него уходило слишком много времени. Поговорили, оказалось — это не от заботы об эффективности, а от страха ошибиться и быть виноватым в падении производительности или всей системы. Решили, что если есть страх, то надо сразу собрать консилиум и принять быстрое решение. Когда решили все вместе, то одного виноватого не бывает.

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

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

Так в нашей практике появился адвокат дьявола — swap позиций для случаев, когда двое спорят и не могут договориться.

Так у нас появился Чингисхан — когда ты одно за другим забраковываешь предложения, чтобы на 5-6 итерации получить идеальное решение. А 5-6 итерация — это минут через 15-20.

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

Был соблазн раздавать задачи по лучшим компетенциям — т.е. тому, кто их лучше всех решал в прошлом. Но, раз мы работали на будущего работодателя, так не годилось, и мы соблюдали баланс. Каждый получал примерно 30 % новых для себя задач. Тут, конечно, шла потеря эффективности, но она краткосрочная, а в долгосрочной перспективе это выигрыш для всех сторон.

Потом мы заметили, что один из нас сопротивляется полученным задачам. Вместо того, чтобы решать, он сидит и придумывает, почему задачу делать не надо — ищет ошибки в постановке, подводные камни и сопутствующий ущерб. Иногда это занимало часы. Ок, разобрались, поговорили, решили: не хочешь решать задачу — не вопрос, только скажи сразу. А если взял — решай.

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

Я все время наблюдал за скоростью и эффективностью, но по инерции делал это раз в день, как на скраме. При этом, чтобы увидеть потери и понять их причину, надо видеть одновременно — и потерю, и причину. Если смотришь сегодня за вчера, то причины уже нет — она осталась позади. Поэтому я вспомнил такую штуку, как контроллинг — не тот, который «контроль», а тот, который «управление на основе цифр», хороший и добрый. И стал наблюдать за приростом баллов в течение дня. Если видел, что у кого-то цифра стоит колом, то шел разговаривать с человеком, и причина быстро находилась. Она была или сиюминутной (затупил), или системной, а это уже повод для улучшений. Этот прием я использовал на протяжении почти всех двух месяцев.
 

Резюме


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

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

См. также

Радио "Аналитик", 15 выпуск 2 сезона. "Путь аналитика" с Ильёй Никитиным. Переход от технической поддержки к анализу

Личная эффективность Обучение и наставничество Бесплатно (free)

В серии “Путь аналитика” мы говорим о том, как аналитики приходят в профессию, с какими задачами работают, с какими трудностями сталкиваются и как их преодолевают.

18.03.2024    285    0    Radio_Analyst    0    

5

Радио "Аналитик", 14 выпуск 2 сезона. "Путь аналитика" с Натальей Лосевой. Переход от разработки к анализу

Личная эффективность Обучение и наставничество Бесплатно (free)

В серии “Путь аналитика” мы говорим о том, как аналитики приходят в профессию, с какими задачами работают, с какими трудностями сталкиваются и как их преодолевают.

04.03.2024    351    0    Radio_Analyst    0    

5

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

Обучение и наставничество Бесплатно (free)

Тема измерения и развития потенциала сотрудников является ведущей последние два года в компании Proaction. Елена Дуюн, руководитель направления «Развитие корпоративной культуры», поделится с нами откровением, которое возникло в процессе исследовательского проекта на платформе Proaction. Елена расскажет о текущей кадровой ситуации, о видах потенциала сотрудников, о том, как оценивать этот потенциал и как мотивировать персонал на саморазвитие.

01.03.2024    370    0    DuyunElena    0    

3

Радио "Аналитик", 13 выпуск 2 сезона. "Путь аналитика" с Анастасией Лощиловой. От финансового директора на заводе до функционального архитектора

Обучение и наставничество Бесплатно (free)

Что отличает аналитика от самурая? Аналитик не прокладывает путь, пока не поставит цель. В серии “Путь аналитика” поговорим, как аналитики приходят в профессию, с какими задачами работают, с какими трудностями сталкиваются и как их преодолевают.

20.02.2024    512    0    Radio_Analyst    0    

1

Презентация продукта как искусство

Презентации и публичные выступления Бесплатно (free)

Никакой продажник не продаст ВАШ продукт лучше ВАС. Но презентация продукта – это не только наука, но и искусство. О том, как сделать выступление запоминающимся, насколько важны базовые ораторские навыки, сторителлинг и инструментарий для наглядного погружения в детали, расскажем в статье.

12.02.2024    935    0    comol    4    

17

Личный бренд в IT: а оно вообще надо?

Личная эффективность Бесплатно (free)

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

01.02.2024    837    0    mitinskiy    2    

7

Зачем программисту книжки читать

Личная эффективность Бесплатно (free)

Нам с детства постоянно твердят, что книга – лучший друг, книга – лучший подарок, книга – вообще лучшая вещь в мире. Да, это действительно так. Книги явно и значительно влияют на нашу работу, карьеру и жизнь. О том, как правильно читать книгу, как книга вообще влияет на человека, и главное: зачем вообще читать эти книги программисту, сисадмину, аналитику, расскажем в статье.

31.01.2024    2846    0    a_a_burlakov    25    

46

Гореть, но не выгорать: как сохранить ресурс специалистов

Коммуникации Мотивация Личная эффективность Бесплатно (free)

Сейчас на рынке много объемных проектов, и специалисты часто сталкиваются c перегрузками. Чтобы сохранить ресурсное состояние и не допустить выгорания, нужна личная работа человека и грамотный подход руководителей. В статье рассказываю, как мы помогаем сотрудникам справиться со стрессом.

15.01.2024    1703    0    KChebykina    0    

31
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Timur.V 78 30.07.18 11:19 Сейчас в теме
Ускорение 4X - у вас было увеличение прибыли собственного бизнеса или по найму?
2. 1c-intelligence 12771 30.07.18 11:22 Сейчас в теме
(1) причем тут увеличение прибыли? Если статья об ускорении разработки.
3. yogaga 30.07.18 11:50 Сейчас в теме
В статье ничего нового, что печально. Но новые статьи будут, что радует.
4. 1c-intelligence 12771 30.07.18 11:53 Сейчас в теме
(3)
Но новые статьи будут, что радует

почему так думаете?
5. yogaga 30.07.18 12:06 Сейчас в теме
Так в этой статье вы не прощаетесь - а уход по-английски не в вашем стиле :)
6. profiprog1c 248 30.07.18 13:44 Сейчас в теме
Вот меня всегда удивляет стиль написания этого автора. Он в упор путает причину со следствием. Он в упор продолжает не понимать,что такое эффективность в бизнесе. Следуя логике статьи автора у них с командой "первопроходцев скрамников" эффективность была 4 бала, а стала 17. Главное, ведь балы считали сами участники "скрамного кружка по интересам", а не внешние люди, которые были бы не заинтересованы в х4 на бумаге ускорении. Далее, эффективность команды "любителей скрама" настолько возросла, что мало того, что они стали получать больше балов (которые сами себе и начисляли), так они еще используя свое рабочее время умудрились написать 20 абстрактных инструментов для себя. Как по мне, вот это и есть реальный показатель загруженности в рабочее время, команды скрама и их х4 ускорение. Сама же статья написана в духе "воспоминаний", как будто автор действительно изобрел что-то полезное и сделал что-то действительно нужное, а с высоты прожитых лет, вспоминает это. А на самом деле, х4 ускорение существует только в нескольких статьях автора на бумаге и в его воспоминаниях. Стиль статьи очень напоминает, так называемые "истории успеха" любителей гербалайфа и прочих прямых продаж. Может автору стоит и податься в сегмент прямых продаж, там такие "истории успеха" очень ценятся.
dumsik; LordKim; Mantis; formica32; +4 3 Ответить
7. 1c-intelligence 12771 30.07.18 13:50 Сейчас в теме
(6) как связана статья с эффективностью бизнеса?
8. profiprog1c 248 30.07.18 13:54 Сейчас в теме
(7) Вот именно, что никак. Никому не нужно мифическое х4 ускорение, которое ни к чему не приводит. Поймите одно, что когда команда разработчиков что-то пишет, об их эффективности должен судить кто-то внешний, который является незаинтересованным человеком. У вас же все ваше х4 ускорение основано на оценке своих действий самим же собой. С таким успехом можно и до х16 ускориться.
9. 1c-intelligence 12771 30.07.18 14:03 Сейчас в теме
(8) а если никак не связано, зачем вы пытаетесь связать?

Бизнес - это сложная система, с множеством элементов и связей. Общая эффективность системы, т.е. бизнеса, описывается никому не известной функцией, в которой каждый элемент и связь имеют свой вес.

Посчитать эффективность бизнеса - не проблема. Понять эту самую функцию, закон существования эффективности, и увидеть в нем роль каждого элемента и связи - довольно сложная задача. Вероятно, поможет регрессионный анализ - он как раз такие задачи решает. Или ТОС тот же.

Понятно одно: с высокой вероятностью, элемент "ИТ-отдел" и его связи имеют ненулевой весовой коэффициент. Но какой он - не известно (если это не франч, например).

Итого, имеем:
1. Влияние ИТ на бизнес есть;
2. Его размер, даже сравнительный - не известен.

Вы, как и многие другие, руководствуетесь мыслью: раз размер влияния не известен, то и нахрен заниматься эффективностью ИТ. Лучше заниматься мифической "эффективностью бизнеса" (продолжая, правда, сидеть в ИТ и заниматься ИТ, а не той самой эффективностью).

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

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

Материал в статье относится ко второй группе.
tolyan_ekb; +1 Ответить
10. profiprog1c 248 30.07.18 14:23 Сейчас в теме
(9) Я вам пытаюсь объяснить, что то, что вы считаете фактом, а именно х4 ускорение, для меня является не фактом. А вы делаете так, сначала заявляете: х4 ускорение существует и для вас это факт без доказательств, а дальше начинаете вокруг этого строить свою теорию, про пятачков, вини пухов, осликов ИА, историю возникновения и прочие "истории успеха", которые далеки от реального бизнеса, где используется ИТ. Вот как раз тех, кто занимаются продажами гербалайфа очень бы заинтересовала ваша история, как "пятеро энтузиастов" узнали о скраме, попробовали и не пошло, но они не сдались, выкинули все, кроме покера и еще чего то там и сделали свой скрам, который назвали х4 ускорение, а также написали еще 20 абстрактных инструментов для себя (ведь это "история успеха", а в ней важно чтобы все было для себя). Кстати, почему вы остановились на х4, а не попробовали х5, что мешало?
11. 1c-intelligence 12771 30.07.18 15:05 Сейчас в теме
(10) о, а давайте местами меняться?

Попробуйте мне доказать, что информация в вашей публикации "Создание произвольной таблицы значений на форме в управляемом приложении программным способом" - не выдуманная хрень, а полезная вещь. Только с фактами неопровержимыми, а не вашими выдумками.
UniversaLL; +1 Ответить
13. profiprog1c 248 30.07.18 15:55 Сейчас в теме
(11) Хахахаха. Сдулись, так и думал. Там комменты и пишите.
jaroslav.h; +1 2 Ответить
14. 1c-intelligence 12771 30.07.18 16:01 Сейчас в теме
(13) так я и не надувался, чтобы сдуваться. Не будете местами меняться?
21. СергейК 51 04.08.18 13:30 Сейчас в теме
(8)
... когда команда разработчиков что-то пишет, об их эффективности должен судить кто-то внешний, который является незаинтересованным человеком. У вас же все ваше х4 ускорение основано на оценке своих действий самим же собой...

На первый взгляд интересная мысль, оценка эффективности внешним человеком.
У Вас есть реальный опыт такого? Как Вы это себе представляете?
Какой то программист не видя готового решения выполняет ту же самую задачу, и на основании затраченного времени решается эффективно ли сработал ИТ отдел?
12. pm74 199 30.07.18 15:28 Сейчас в теме
(0) Иван приветствую. Когда про метадату напишете ?
15. 1c-intelligence 12771 30.07.18 16:02 Сейчас в теме
(12) что именно интересно узнать про метадату?
16. pm74 199 30.07.18 16:09 Сейчас в теме
(15) примеры интересны. ну например можно ли написать запрос для коучдб в стиле 1с (скл)
19. unpete 577 31.07.18 10:28 Сейчас в теме
(16)
запрос для коучдб в стиле 1с
В общем случае - нет. Вы можете написать map/reduce индекс, результат можно забрать прямо из индекса или пропустить через некую proxy-службу, которая выполнит постобработку. Выборки данных в NoSQL могут быть очень эффективными - обслуживать тысячи параллельных запросов, расходуя минимум памяти и процессорного времени При этом, couchdb не предназначена для работы с произвольными фильтрами, особенно, по сгруппированным данным (having) - для этого мы используем другие инструменты.
17. pm74 199 30.07.18 16:16 Сейчас в теме
(15) у меня (в работе) производственное предприятие , с интерфейсами для рабочих , все это крутится в 1с , в принципе все простые интерфейсы можно было бы вынести во внешнюю среду связанную с 1с . вот и примеряю метадату под себя ))
18. leemuar 30.07.18 16:51 Сейчас в теме
(17) hello world на metadata выложен же в сеть, еще и библиотеки все есть на гитхабе. (https://github.com/oknosoft/metadata-devtraining)
Вы их пробовали?
20. unpete 577 31.07.18 10:37 Сейчас в теме
(17)
вынести во внешнюю среду связанную с 1с
У наших клиентов, ответственные задачи возложены на метадату, а 1С выполняет вспомогательные, учетные функции, но ваша модель, так же, имеет право на существование.
При правильной организации данных, цеховые рабочие места, смогут функционировать даже при отсутствии связи и физическом уничтожении сервера динамитом, а когда привезут новый сервер, данные безопасно реплицируются.
22. Michael0507 05.08.18 12:53 Сейчас в теме
Почитал про покер планирования - там ли срок в днях, либо сложность в баллах. Как я понимаю у вас средняя сложность баллов в день? Можно поподробнее рассказать, как рассчитывали эти баллы?
23. Michael0507 05.08.18 16:27 Сейчас в теме
Оставьте свое сообщение