<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
Скриншоты такие мелкие и не читабельные специально?
Тема «российской действительности» не раскрыта 🙂
Я прямо вместо каждого переноса строки вижу слово «простой».
Отдел продаж перешел на канбан первый, и говорит сборочному цеху, «авто продано, сделайте еще одно», цех сборки делает авто, отправляет на «стенд, и говорит» «авто собрано, привезите еще кузов, двигатель и 4 колеса», цех двигателей делает двигатель и в 16:00 уходит домой, цех кузовщиков работает ровно до 17.00 и как обычные работяги с завода идут курить кальян и пить смузи, а литейный цех 2 часа разогревает печь, 15 минут выливает 4 шины, 20 минут собирает шины в колеса, а потом идет увольняться, потому что он получает 40 грн за колесо, а 160 грн в день — это ~120 долларов в месяц, а у рабочего жена, ребенок и тёща.
Через 3 дня приезжает дядя и говорит «я из министерства клавиатур, и мы решили подарить 10 лучшим машинистам страны по машине, конкурс послезавтра, платим тройную цену». Что ответит ОП кроме «нет»?
А теперь вопрос: как должен происходить переход на эту систему, и что делать в пик (аврал)?
Российская действительность в отличие от японской состоит в том, что у кнопки диалога windows там три варианта ответа: Да, Нет, Фиг его знает.
И вот канбан (скрам и еще много других страшных слов) мастер нанятый коммерческим директором заводит доску с карточками, коммерческий директор приводит посмотреть на это благолепие генерального.
Генеральный офигевает как теперь он круто всеми управляет и наступает идиллия.
До визита генерального к владельцу бизнеса, который паренек прокуренный и спрашивает что сделано конкретно.
А не сделано ничего, потому как все задачи в статусе Фиг его знает.
После этого по пищевой цепочке вниз все получают волшебный пендель и все задачи переходят в статус сделать вчера.
Канбан (скрам и еще много других страшных слов) мастер тихонько вешается, разрабы выходят в ночь на недельку и все разруливают.
После этого наступает квартальная премия и умиротворение.
Директора всех уровней задувают дымящиеся фитили, Канбан доска зарастает паутиной, Канбан (скрам и еще много других страшных слов) мастер бухает с разрабами… все возвращается на круги своя.
Канбан идеален для автомобильной промышленности, и там он работает даже в России. Для других отраслей его надо адаптировать.
Я вот одного не поняла, где копятся задачи свыше установленного лимита? Где лог с приоритетами не запланированных задач
Запутался в разделе «Принцип второй».
Сначала идёт пример со школьной столовой, где 1 повар не успевает обслужить школьников (имеем ограниченные ресурсы и неограниченное количество клиентов). Решение — ограничиваем количество задач.
Потом идёт пример с производством авто где производство превышает потребности клиентов. Решение — производим только по заказам клиентов, то есть ограничиваем свои ресурсы.
Как объединить эти 2 противоположенных по смыслу примера в один принцип?
По поводу со столовой можно порассуждать еще на тему «и чем Макдональдс отличается от чайной церемонии..»
(1) rpgshnik — в общем, да. Там никакой конструктивной информации нет.
Есть, пожалуй, в кумулятивной диаграмме потока (последний скриншот), но по ней я лучше отдельную статью напишу, там есть что рассказать.
(3)
Прикол в том, что простой — это не хуже, чем ненужная работа
Я искренне сочувствую рабочему, у которого жена, ребенок и тёща. Но с точки зрения директора предприятия платить рабочему за простой нерентабельно.
Через 3 дня приезжает дядя и говорит «я из министерства клавиатур, и мы решили подарить 10 лучшим машинистам страны по машине, конкурс послезавтра, платим тройную цену». Что ответит ОП кроме «нет»?
Если он имеет разумный запас — он молодец. Если он имеет переполненные склады ненужной продукции — он не молодец.
А теперь вопрос: как должен происходить переход на эту систему, и что делать в пик (аврал)?
Это отдельная тема, отвечу чуть позже.
(6) katenok86 — бэклог, там и копятся. Там их может быть много. Но если уж задачу взяли в работу — то сделают быстро. На практике бизнесу ценнее знать, что небольшое количество могут сделать быстро, чем знать, что большое копится в работе, а когда будет сделано — фиг знает, как тут выше описано…
(11)А если в беклоге лежат задачи по проектам, с учетом того что нужно вписать их в ограниченное время с учетом ограниченных ресурсов? Получается на канбан ведется только текущее оперативное планирование? А среднее и долгосрочное где то еще?
Просто пытаюсь вписать его в методику ведения проектной деятельности.
(5) Конечно. Всецело согласна. Любую методологию нужно адаптировать.
(10) Да, в принципе даже до канбана тоже будет простой, если так задуматься… Но вот на практике метод «гусеница» работает четче: сначала попа гусеницы ползет быстрее головы (производство работает в поте лица), потом останавливается (вахтовая смена, 1 через 2 итд), а ОП постепенно продает (голова гусеницы поползла). так как продажи сложнее расчитать чем производство: клиенты могут быть перетянуты конкурентами, или наоборот к конкурентам придут третьи конкуренты и сожгут все к чертям, а клиенты прибегут к вам и прочие факторы
(7) Суть вытягивающей системы в том, что мы делаем не столько сколько можем (пределом является ограничение по ресурсам), а столько — сколько закажут (пределом является входящий поток). Если ресурсов больше, чем заявок — хорошо, успеем все. Если меньше — успеем только то, что успеем.
Для примера столовой — мы не пускаем в зону раздачи людей больше, чем можем обслужить. В единицу времени.
Для завода — мы не делаем заготовок (полуфабрикатов) больше, чем нужно отгрузить. В единицу времени.
Естественно, что на производстве всегда есть небольшие переходящие запасы. И очень важной частью канбан системы как раз является правильный расчет объема этих запасов.
При «вытягивании» мы же не можем выдать продукт сразу при получении заказа. Его нужно еще изготовить. И пока он будет изготавливаться, как раз и должны работать промежуточные запасы, обеспечивая непрерывность цепочки.
В чем еще очень большой плюс канбан системы — её можно внедрить вообще без автоматизации, исключительно на бумажных карточках. И все будет работать.
У нас, например, таким образом реализована система управления запасами комплектующих и расходных материалов для вычислительной и оргтехники. На бумажных карточках. Если интересно — могу рассказать подробнее. Может быть даже в формате статьи.
(15) Интересно.
Расскажите, пожалуйста.
(15) Но надо учитывать, что чисто «вытягивающая» система не всегда может быть применена.
(12) Да, совершенно верно, канбан позволяет вести текущее оперативное планирование. Нюанс в том, что если мы повышаем общую предсказуемость (мы знаем, что в среднем разрабатываем 3 фичи в неделю), то мы можем предсказать, когда разработаем тот или иной результат и в длительной перспективе.
(18)
Не согласна. Точнее не так, это применимо для более менее стандартных тиражных задач. В случае с индивидуальным проектами (в частности речь про проекты внедрения 1с у крупных заказчиков) все не так предсказуемо.
Канбан — это суши, которое Российскому бизнесу не проглотить.
В отличии от скрама, канбан нельзя внедрить локально в одном отделе. Нужно комплексное внедрение на всём предприятии. А это значит, что инициатива должна исходить в первую очередь от собственника бизнеса. К сожалению в нашей стране не все собственники готовы к организации такого порядка.
Отличная штука, этот канбан. Но мне кажется, что автор либо что-то недоговаривает, либо чего-то недопонимает. Ведь, например, в автомобилестроении планирование идёт на многие годы. И хоть планируется всё исключительно от продаж, но риски там тоже огромные, которые могут скорректировать применимость ранее заготовленных деталек.
Мне кажется (только кажется, т.к. тонкостей не знаю), что описанная методика годится только для мелких и легкоформализуемых задач. Например, для небольшого франча или для тех автоматизаторов, которые в совершенстве владеют методикой «втюхивания залипух»
Спасибо за статью. Всё просто и по делу… действительно сумели кратко отразить суть
(22) comol — спасибо на добром слове.
(21)
strange2007 — непростой вопрос. Канбан-система, несомненно, может подойти как инструмент внутреннего управления задачами для франчайзи независимо от размера проекта. Даже если у вас комплексное многомиллионное внедрение, внутри него в любом случае будут отдельные крупные блоки, которые можно разделить на пользовательские требования, а их в свою очередь — на технические задачи, которые отражать на канбан-доске. Так что по моему опыту, применимость канбан-доски прямо с размером проекта не связана.
Если же говорить о размере не проекта, а задач — то здесь можно разные задачи размещать на разных «плавательных дорожках» (допустим — новая разработка, техподдержка, технический долг и т. п.), и можно сделать даже разные WIP-лимиты для разных задач.
(20)
taurus_ — несомненно с вами согласна, не все собственники. Но некоторые готовы, поверьте моему опыту. И постепенно лёд трогается во многих местах. Крупные компании — Сбербанк, Альфабанк, Ростелеком — уже потихоньку переходят на Agile. Сама компания 1С рассказывает про применение Канбан-системы и предлагает франчайзи применять гибкие методы управления (по-крайней мере, для небольших проектов). Так что я верю, что постепенно бизнес изменится в сторону готовности к гибким подходам.
(8) Ну, Макдональдс про то, чтобы обслужить как можно больше клиентов… А чайная церемония — она ради процесса и удовольствия… Давайте не будем хотя бы чайную церемонию оптимизировать )))
(17) Конечно, не всегда. Универсальных инструментов вообще не бывает.
Хотя интересно, если вы раскроете, что именно вы имеете в виду? Бывают ситуации, когда «выталкивающая» система эффективнее?
(19)
Скажем честно, в случае с проектами внедрения 1С у крупных заказчиков предсказать скорость выполнения задач вообще не просто. Канбан можно использовать как один из инструментов для грубой прикидки на основе статистики — скажем, мы видим, что у нас выполнение одного требования заказчика (которое потом декомпозируется аналитиком на конкретные технические задачи) занимает от 1 дня до 2-ух недель, в среднем — 1 неделю. Исходя из этого, мы можем предположить, что если этих требований осталось еще 48, то нам осталось порядка 48 человеко-недель работы… Высокой точности у нас не будет, но будет сильно лучше, чем ничего. (Это без учета новых требований, которые будут появляться в процессе).
(24) Упс… Если обидел, то извините. Моя мысль (сомнение) возникла из-за концепции вытягивания. Ну не укладывается она в моей голове в рамках многолетних планирований. Если идти от плана к факту, то да, план тянет за собой фактические действия. А вот между различными отделами эта концепция ну совсем не работает. Даже на производстве холодильников, где планирование всего на несколько лет, вытягивание в принципе не может работать. Помню, когда заходил туда, встал вопрос о смене отечественных компрессоров на австрийские. Потребность у покупателя была именно в отечественных компрессорах (привычные, зарекомендовавшие себя, все мощности под них настроены и т.д.), но аналитики завода предсказали, что покупатель захочет западную технику покупать через столько то лет. И поэтому всё производство начали менять задолго до запланированных продаж. и конечно же прогнозы провалились и пришлось быстро менять эти злополучные компрессоры на китайские.
Понимаете, в стратегических масштабах я не могу придумать как применить концепцию, описанную Вами. А вот в мелких областях да, вполне применимо.
В ИТ-проектах тоже не всё так гладко. Если задачи более-менее формализуемы, тогда всё нормально. Но как только получаем «размытую» задачу, то всё упирается в стену. В своё время сколько мы бились над декомпозицией монстров и всё время как-то плохо получалось. В итоге смотрели опыт разных мастодонтов и в итоге скрестили из их опыта более-менее нормальную методику. Но это другая тема.
Но ещё раз повторюсь — методика Канбан очень и очень интересная.
Примечание: По некоторым причинам японские и немецкие методики надо применять очень и очень аккуратно
[А можно где то ее раскрыть? Правда интересно
стало очень любопытно — неужели под 1С.Документооборот никто канбан не запилил?
по моему это именно та система, куда доска очень просится.
(31)
Еще как запилили! На инфостарте есть некоторое количество конфигураций разной степени допиленности и готовности к коммерческому использованию, вот здесь .
(33) а вот кстати и нет. По результатам поиска 3 самостоятельные конфигурации и 1 «приделка» на УТ.
на документооборот ничего нет.
(34) Кстати, да, вы правы. Действительно интересно почему, на самом деле… Может быть, Документооборот слишком громоздкий?..
(35) документооборот на самом деле громоздкий, ресурсоёмкий и малопонятный для большинства разработчиков. Для пользователей, собственно, тоже 🙂
Также присутствует ощущение, что сама 1С находится в «творческом поиске» в отношении документооборота.
Технологический задел неплохой.
Но вот как раз наглядности, визуализации совсем не достает. Выглядит и шевелится все так «мертвенько и в кучке». Что то типа «канбана» было бы в самый раз. Мне кажется продукт стал бы принципиально другой привлекательности.
Здесь приобретал конфигурацию «Управление ИТ отделом», там немного похожие механизмы. И в плане управления задачами тоже все так в кучку, вечером закрыл 1С, утром открыл — глаза разбегаются, не вспомнить на чем остановился. Вот в танце натянули на конфигурацию «канбан», работа принципиально оживилась. И как руководителю — контролировать наглядно.
(36)
Воот, не только у меня такое ощущение )))… Все пользователи Документооборота, с кем я общалась, уважительно говорили — мол, какая солидная махина… Но без крайней необходимости старались не пользоваться ))). Я подозреваю, что при попытке натянуть Канбан на документооборот, он скорее всего, унаследует ту же громоздкость.
(37) может быть. Канбан или любой другой внятный «юзабилити» механизм туда прям напрашивается, но насколько реально, не знаю. Интересно.
Компании 1С что то надо с этим делать, иначе, мне кажется, это тупиковая ветвь развития. Вокруг столько классных систем, а тут бац — «колосс на глиняных ногах» 🙂 Но это уже не по теме.
(38)
Microsoft, кстати, к последней версии Проджекта прикрутили Канбан-доску — ибо тренд уже всем очевиден. Думаю, и 1С не останется в стороне — ещё чуть-чуть подождать ))).
Отличная статья!
(38) «колосс на глиняных ногах» — это серая инертная масса партнеров и клиентов, на которых ориентируется 1С. Для которых вынуждена создавать «нужные» им продукты.
(38) Компания 1С завязла на внедрении документооборота на Почте России, поэтому следующий релиз ДО будет на основании этого проекта. Используется ли там канбан? Не думаю…
(41) не очень согласен.
почти как в любом ритейле, не клиент управляет продавцом, а продавец управляет клиентом.
1С в этом хорошо преуспела, и явно не «вынуждена», а «делайте так как сказано» 🙂
(42)
печально 🙂
хотя канбан всего лишь один из инструментов визуализации задач и процессов, которые в ДО по умолчанию имеются.
(43) Ок, вы как-то вынуждены делать то что вам навязывают? В России это НЕ работает. При всем моем 20 летнем уважении к фирме 1С, всегда покупал только то, что мне необходимо.
(44) думаю Почта России может себе позволить написать ДО с нуля. 😉
Канбан из гут 😉
(45)почему не работает? Именно это и работает, особенно в России на фоне отсутствующей конкуренции.
1С.ЗУП — мы начисляем з/п и ведем кадровый учет именно так, как считает 1С, не смотря на многообразие способов и форм учета.
1С.БУХ — ПБУ и НК РФ конечно вещь регламентированная, но все связанные сервисы, например 1С.ЭДО, 1С.МДЛП и т.д и т.п. мы вынуждены или будем вынуждены использовать так как предлагает 1С, а не как мы хотим. Ну либо вкладываться по серьезному и делать самим.
1С.Розница — тоже, почему 1С решила что именно такой учет в рознице должен быть? Почему именно такой маркетинг должен быть?
1С.УТ — аналогичная ситуация. Хотя здесь мы вольны переписывать все вдоль и поперек и у кого денег есть — переписывают почти полностью. Но все равно ж 1С. Стандартные библиотеки, БСП, обмены — и как следствие ИТС — все это 1с.
1С.ДО — еще более яркий пример.
и т.д и т.п.
при всем многообразии выбора у нас выбора то нет.
Как говорят маркетологи — то что нам кажется, что в супермаркете мы сами выбираем себе молоко — это нам только лишь кажется.
(47) Сочувствую 😉
(47) Случай с ДО и Почтой какраз таки наглядно продемонстрировал ущербный подход 1С к методологии типовых решений…
(43)
почти как в любом ритейле, не клиент управляет продавцом, а продавец управляет клиентом.
1С в этом хорошо преуспела, и явно не «вынуждена», а «делайте так как сказано» 🙂
Вот мои ощущения тоже подсказывают, что 1С скорее делает так, как ей удобно. А окружающие подстраиваются.
(40) Rico17 — спасибо на добром слове!..
(46) Ну, Почта России же не сама решает, как организовывать документооборот… А 1С удобнее единый продукт создавать, и дальше уже его предлагать другим клиентам.
(29)
Да все методики надо применять очень и очень аккуратно ))).
Я вообще всегда начинаю консультации со слов «работает — не трогай!!!».
У российских компаний меньше горизонт планирования, не всегда практикуется регулярный менеджмент, тема этики и репутации нередко менее актуальна, чем на западе.
(13) Maria позвольте вопрос.
Про физическую канбан-доску. Работал в организации, где была физическая доска со стикерами и ежедневно происходил чек-статус по этим карточкам. Так вот: каждый день (!) примерно на час все (!) разработчики и другие причастные выпадали из рабочего процесса на проведение синхронизации статусов на доске и реальных статусов. Разработчиков человек 15, WIP лимит не более 2-х задач одновременно, актуализацию статусов ведут 2 человека.
Вопросы:
1. Чем физическая доска лучше электронной? Кроме «мышечной памяти», с точки зрения рабочего процесса.
2. Кто и как должен на физической доске выполнять обновление статусов карточек задач?
3. Как в этом процесс должны (если должны) участвовать остальные участники процесса?
4. Представители Заказчика должны присутствовать при обновлении статусов?
5. Какие выводы должны быть сделаны каждым из участников процесса после обновления статусов? Их ведь обновляют, чтобы наглядно увидеть где задача начала буксовать, а где она уже утонула в производственном болоте. Значит должны делаться какие-то выводы, приниматься решения. Что должно происходить дальше?
Меня лично беспокоила (читай — напрягала) крайне низкая эффективность от влияния физического канбана на процесс производства ПО. Другими словами от него было больше вреда, чем пользы, на мой взгляд. Это больше похоже на ритуал карго-культа, без понимания сути.
Вот мне, с вашей помощью, и хочется понять, как должен выглядеть канбан здорового человека. Особенно с использованием физической доски, раз уж она представляется лучшей чем электронная.
Спасибо.
(54) Канбан — это «вещная вещь». Для того чтобы он взлетел, необходимы четкие алгоритмы и однозначная идентификация событий при которых эту карточку надо взять и переклеить (или поменять статус).
Вы тратили время не на синхронизацию статусов, а в принципе на их определение. Какую задачу можно считать сделанной/принятой/буксующей/утонувшей.
(55)
До описанной ситуации, в другой компании, я использовал методики канбан для управления процессом и там все было отлично, никаких ощутимых затрат на ведение самой канбан-доски. Но это было то, как понимал канбан я и при несколько меньшем количестве участников. Использовал Trello. Подобных проблем не наблюдалось, потому что я предварительно сам собирал информацию от исполнителей и сам проставлял статусы. Все происходило очень быстро. Больше 15 минут в день процесс не занимал.
В описанной ситуации я был одним из участников, в уже имеющейся системе.
Вот и хотелось понять, чье видение (понимание) как должна работать методика более правильная, и как вообще должно быть в этих моментах (которые я задал Maria) с точки зрения человека теоретически подкованного и знающего «как правильно». ))
И мне понравилось, Вы хорошо подметили: «Вы тратили время не на синхронизацию статусов, а в принципе на их определение.». Действительно большая часть времени тратилась на это, скажем 80%. Еще 20% таки тратилось на синхронизацию самой доски, т.к. она распределена по двум городам. Надо над этим поразмышлять…
Добрый день, коллеги!
Пожалуйста, помогите разобраться. Наша команда (ИТ-отдел на предприятии) в том состоянии, когда куча задач срочнее срочного и все сроки горят и всё неуправляемо. Мы ищем решение наших проблем.
Вопросы касаемо первого принципа.
Доска мне понятна, когда перемещаю «маленькие» карточки такие как «сделать печатную форму», «исправить ошибку» и т. д. Перемещаем анализ-разработка-тестирование-готово. В данном случае перемещаю в моём понимании Требование клиента, не задачу. Под задачей понимаю то, что должен сделать один человек. Например, разработать ТЗ; согласовать ТЗ; создать обработку; протестировать обработку; передать обработку заказчику; исправить ошибку в обработке; передать обработку снова заказчику и т.д.
Когда требование заказчика большое (например, реализовать обмен между тремя программами), то мы его декомпозируем: реализовать обмен ПО1-ПО2, реализовать обмен ПО1-ПО3. Верно ли я понимаю, что на доске должно быть 2 карточки (обмен ПО1-ПО2 и обмен ПО1-ПО3)? «Большой» карточки на этой доске не будет или она должна быть где-то на другой доске? Как быстро собрать информацию в данном случае о состоянии реализации требования? Когда на доске много разных карточек то мне надо вспомнить, что были именно 2 карточки, а потом надо их найти на доске?
На физической доске мы бы добавили горизонтальное разделение под крупные требования. Однако в Trello такого нет (или мы плохо искали?).
Ещё есть задачи не разработки, а выполнения какой-то работы. Например, массово переделать документы (заменить склад). В данной статье приведён пример доски из Trello. По столбцам очень похожа на нашу. И здесь такая задача не вписывается. Добавить столбец «Сопровождение» или вынести на отдельную доску?
Как сотруднику, глядя на доску, определить порядок работ на сегодня в том случае, когда сотрудник должен выполнять карточки из разных столбцов?
Например, мне (менеджеру на все руки) надо пробегаться по этой доске: по ряду требований надо напомнить заказчику принять результат, ряд реализованных требований протестировать, где-то написать инструкцию пользователя и провести обучение, где-то подготовить концепцию и согласовать с заказчиком и т.д. И глядя на доску, не понимаю чем сегодня заняться — всё не успею. Из этого перечня выбираю себе задачи на сегодня — делаю свой мини список… И опять какой-то отдельный список.
(57)
Как вариант выделять цветом. А если физическая доска, то можно внешним видом, ну типа — треугольник это сопровождение, квадрат — проектная задача …
(57)
Стоп! Мне кажется, что если у вас в подразделении один и тот же сотрудник делает работу из разных столбцов — то это не правильно. Т.е. должен быть тогда один столбец у которого ограничена «мощность» (объем задач), т.е. остальные задачи копятся на входе.
(57)
Вопрос, как у вас организован процесс. На мой взгляд, где-то карточка общая должна быть, и по ней нужно отслеживать статус. У нас за этот процесс отвечают аналитики, а за сами задачи — уже разработчики.
Если речь о физической доске идет — то мы просто нумерацию добавляем в формате 1.1. 1.1.1., 1.1.2. и т. п.
На физической доске мы бы добавили горизонтальное разделение под крупные требования. Однако в Trello такого нет (или мы плохо искали?).
В Трелло точно есть цветовая маркировка, которую можно настроить как удобно, и можно ставить ссылки на другие доски.
И глядя на доску, не понимаю чем сегодня заняться — всё не успею. Из этого перечня выбираю себе задачи на сегодня — делаю свой мини список… И опять какой-то отдельный список.
Ну, это уже, конечно, является признаком ситуации «не очень в духе Канбан» — у нас одна из целей — минимизация незавершенки.
Общий принцип по умолчанию — мы стараемся сначала продвигать задачи, которые у нас ближе к концу, чтобы уменьшить число задач на доске.
(58)
Артур, мне кажется, что здесь у нас, как обычно, конфликт между «идеальной» картинкой и «реальной».
В нашей практике, например, бизнес-процесс мог выглядеть таким образом:
Требование проходит этапы: «Разработка», «Техническое тестирование», потом уходит на «Функциональное тестирование» к пользователю, потом возвращается к разработчику на этап «Документирование и обучение». И WIP-лимит у разработчика получается общий на все 3 колонки.
(60)
В нашей практике, например, бизнес-процесс мог выглядеть таким образом:
Требование проходит этапы: «Разработка», «Техническое тестирование», потом уходит на «Функциональное тестирование» к пользователю, потом возвращается к разработчику на этап «Документирование и обучение». И WIP-лимит у разработчика получается общий на все 3 колонки.
Да Мария, есть постоянство в этом мире — его несовершенство 🙂 С тремя колонками и общим WIP-лимитом согласен, но остальное все равно болтается, пока WIP-лимит не позволит пройти, это ключевое. Приоритет по выполнению — справа налево (вытягиваем), и прием свободных задач также справа-налево (из тестирования в обучение, а уж потом новая с бэклога).
А иначе кабанчик помрет не начавшись 🙂
(4) я так понимаю канбан-система зародилась в Японии — в которой мастера цехов настолько же ответственные и дисциплинированные, как и менеджеры среднего звена, как и руководители (топ-менеджеры)…
у нас на любом уровне можно встретить безответственность и отсутствие дисциплины: «будь проще, и к тебе люди потянутся», » и так сойдет», «время покажет», «авось….»
я так полагаю, если в отделе все заинтересованы в улучшениях, то канбан-система и, в частности, канбан-доска будет приносить людям пользу.
(19) надо сделать «предсказуемым», надо обучать Заказчика , притормаживать его со своими хотелками, не идти на поводу «срочно и быстро».
это же ваш выбор — делать проект «в гонке» или технично по канбан-системе.
(20) не готовы — значит не готовы, пусть это будет их головная боль. главное, чтобы вы в своей практике внедрили улучшения… можно начать с канбан-доски…
автор видимо не знает, что канбан (карточка в Производственной Системе Тойота) и Канбан метод, предложенный Дэвидом Андерсоном в Майкрософт не имеют ничего общего. первое — для материального производства, второе — для интеллектуальной деятельности. а название похожее. пожелаю автору пройти для начала курс от LeanKanban Univertsity и получить хотябы степень KMP
PS для читателей блога — есть официальный подход по применению Канбан метода — STATIK, легко гуглится