<?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='\
Давайте я расскажу вам, почему ваши заказчики довольны здесь и сейчас, и почему они вас проклянут, когда вы уйдёте.
Они довольны потому что:
1. Заказчик обожает людей, которые просто приходят и делают, так как он сказал, результат через неделю. Разрабатывать техническое задание на всю систему долго и сложно, необходимы люди со стороны заказчика и исполнителя. Это время и деньги. Намного приятней, когда директор говорит «Сделайте мне вот эту рюшечку», а заказчик делает.
2. Заказчик обожает платить за проделанную работу, а не за ту, которая будет сделана. Очень часто хорошее продуманное тех задание дороже и трудозатратней чем вся оставшаяся работа. Для многих заказчиков это выглядит как плата за воздух.
Заказчики проклянут вас потому что:
1. Итоговая работа по сиюминутным требованиям будет дороже, чем та же работа по продуманному тех заданию.
2. Если заказчик сядет и подсчитает время, которое затратил, то поймёт что продуманное тех задание было сделать быстрее, чем каждый раз указывать вам что ему ещё хочется.
3. В итоге заказчик получает систему с большим количеством ненужных модулей которые никогда не будут использоваться и не до конца оптимизированными и автоматизированными другими функциями, которыми он пользуется.
Это только то, что пришло на ум сейчас и сразу, если заглянуть в глубь, там всё ещё печальней.
PS. В самом начале вы приводите диаграмму работы с заказчиком над его системой в течении 8 лет, а ниже пишите «разработать систему управления складом (WMS) за 90 дней и сэкономить заказчику 2000 долларов на каждом рабочем месте». Получается вы за 3 месяца сделали базовую функциональность WMS, сэкономили заказчику 2000 долларов, а после допиливали вашу поделку ещё 94 месяца, т.к. переплата времени и денег колоссальна. Могу с уверенностью говорить, что за 3 месяца заказчик может выбрать и начать внедрять устоявшуюся и продвинутую WMS систему, а после стабильно и без потери времени и денег на ней работать.
(1) Чем это лучше — заказчик купил WMS в которой все есть и потом 94 месяца пытается ее у себя внедрить, а консультанты консультируют «это все есть, просто вы не умеете пользоваться», а в результате натягиваем бизнес процессы предприятия на модель WMS?
p.s.: давайте в споре опустим момент, что навороченная WMS самая правильная и разрабатывалась она для одних типов складов, а продали для другого… (например мелкая и крупная фасовка).
p.s.s:
Вставлю свои пятьдесят копеек, так как промолчать не могу (ввиду имеющегося опыта работы по складским технологиям).
Дабы не быть рамилем, буду пояснять все на себе.
Первое:
Внятное ТЕХЗАДАНИЕ (а !!техпроект!! еще раньше должен делаться) — составить весьма проблематично.
Беря свой склад — на этапе разработки техПРОЕКТА (даже не техзадания!) — несмотря на то, что склад у меня по логистике прост до безобразия и вообщем бизнесспроцессы были мной давно обсосоаны и внедрены — разработка техпроекта заналя ДВА МЕСЯЦА (примерно по 2-3 дня в неделю) — имеено потому что была попытка сделать техпроект, подробно описывающий ФУНКЦИОНАЛЬНОСТЬ wms — по факту все равно получилось достаточно обще. Во что выльется подробное ТЕХЗАДАНИЕ при такого рода работах — я даже боюсь себе представить
Второе:
Еслив конторе есть свои вменяемые программисты и есть свой вменяемый спец по складу — и склад не меняется в своей логистике/бизнеспроцессах каждые три недели — дешевле, ЛУЧШЕ и быстрее — будет написать требуемую WMS самим.
Если в конторе есть вменяемые программисты, но нет спеца по складу — нанимаем консультанта по складу и под его дудку а) пишем сами с нуля б) покупаем базовое промышленное решение и дописываем сами дальше по дудку консультанта.
Какие есть трудности: отдельные консультанты, не специализирующиеся на какой-то кокнкретной wms — вряд ли пригодятся, а если и пригодятся то на самом начальном уровне — на уровне «выпрямления» функциональности склада, ковыряться во внутренностях вмс придется программерам самим — что вообщем будет непросто… А если нанимать консультанта из самой конторы, которая продала ВМС — вряд ли вмсники будут в этом заинтересованы — потому как само базовое решение которое можно купить аs is — это процентов 30% от стоимости проетка итоговой.
В итоге: что получилось у меня. Очень долго, некачественно допрограммирование над базовым функционалом. Приходилось практически работать тестировщиком. Выпиливание бьагов и косяков и неудобств идет до сих пор (проект еще не финиширован), хотя по факту стартанули в работу с 26 мая (колбасило всего три дня). далее более-менее нормально.
Если на складе был «бардак» до начала его автоматизации, то подход как в публикации — мне кажется весьма оправданным — за относительно небольшую плату можно получить автоматизацию ключевых/тяжелых участков. А вот собственно СИСТЕМУ как таковую — уже «писать» потом… отдельно..
(3) CheBurator, я знал, что не удержишся. А еще прикольно, когда новые доработки ломают старые реализации и появляется необходимость в регрессионном тестировании 🙂
(6) оно, оно, точно!
вот у меня cqtxfc стоит такая штука как разработка «монитор аролей» складского персонала — то есть динамическое переназначение персонала склада по участкам в зависимости от наличия заданий — так эта штука в принципе «ломает» (как я себе представляю) штатный механизм «зашел в менюшку — выбрал что делать»… и это все тестировать придется и проверять…
Насчет внедрения ВМС — на тех участках, где у меня была спмописная вмс — внедрение большой вмс не дало никакого эффекта, даже кое-где чуток похуже стало.
(1) Dragonim,
Это абсолютно разные заказчики. WMS сделано за 90 дней прошлой весной, а на диаграмме приведен пример другого заказчика, за время сотрудничества с которым успешно решено несколько проектов. Самый короткий проект на 1С:Консолидации выполнен был за 4 недели, из которых 1 неделю выбирали инструмент, на котором делать. Другие проекты связаны с переводом заказчика от учета в УПП 1.1 на УСО и обратно на УПП 1.2 с соответствующими доработками. Если бы требовалось создавать ТЗ или техпроект, то Консолидация бы совсем не взлетела, а в проектах УПП были бы где-то в начале пути (дописка УПП 1.1).
Этот заказчик уже понял, что работающая WMS лучше технического задания за тот же срок и стоимость.
Ошибаетесь, мы сначала реализуем принципиально необходимые требования, предоставляя работающее решение в кротчайший срок. К работающему решению гораздо легче высказать отклонения, устраняемые в последующие несколько итераций. Итог — существенная экономия.
За 2 месяца получилось работающее решение, за оставшийся месяц выполнили тонкую настройку и, на всякий случай, сделали резервный интерфейс, на случай задержек поставки оборудования или отказа электроники и получения возможности отработать без простоев, с использованием резервной «бумажной» технологии.
(9)
Отличный пример «зачем нужно развернутое тех задание и почему оно экономит время и деньги».
Это говорит только о том, что заказчик сам не знает что ему надо, но хочет потратить деньги, а вы не умеете писать ТЗ.
(10) Dragonim, можно посмотреть пример ТЗ?
Там люди вставляли 50 и 5 копеек, а я вставлю 1 копейку… 🙂
Очень интересная вещь описана и честно говоря, вызывает одобрение.
Мое ощущение от описания технологии в статье — по большому счету, речь идет о том, чтобы процесс внедрения (проектирования, разработки, доработки и т.п.) продукта на одном заказчике (один большой проект) разбить на максимально возможное количество логически более-менее законченных задач-модулей (максимально атомарных и автономных). Иначе говоря, если заказчик хочет с нуля внедрить у себя скажем, бухгалтерию, то «обычный правильный путь» — это составить вначале большущий и красивейший проект (техзадание), а потом по его плану работать (я конечно, ужасно огрубляю и утрирую). А вместо этого общий проект разбивается на ряд локальных задач (действующих в рамках одного проекта-пространства) и уже каждая из них решается отдельно, атомарно, практически как мини-проект.
Что естественно легче — с маленькой задачей проще орудовать во всех смыслах. Это плюс.
Второй плюс — заказчик быстро видит результат (прогресс будет постоянный налицо — то там сделали, то тут сделали).
Из приведенного списка претензий к гибкой технологии:
«по гибкой технологии можно делать только маленькие проекты» — собственно сам смысл технологии именно в том, чтобы разбить большой проект на мини-проекты. Маленький проект, я так понимаю, будет разбит всего на 1-2 модуля.
«частые изменения увеличивают срок» и «дорого из-за частых уточнений» — частично справедливо
«отсутствует документация» и «невозможно продать проект без технического задания» — ну определенная документация все равно составляется, даже на небольших задачах, да и есть смысл в словах выступавших здесь, что заказчик порой не любит платить за то, «чего еще нет», т.е. техзадание (проект) считает чуть ли не обманом себя.
«т.к. отсутствует фиксированная цена проекта – будет сложно планировать бюджет» и «отсутствует долгосрочное планирование» — в реальности просчитать заранее весь проект большой точно нереально (доработки будут), да и заказчики часто весьма приблизительно на самом деле знают какой объем проекта им нужен. Как мне кажется, наличие серии мини-проектов даже облегчит жизнь заказчику, т.к. можно будет отказаться или принять каждую отдельную часть.
«низкое качество кода» — не претензия вообще, т.к. качество кода зависит исключительно от квалификации конкретных программистов, а не от величины проекта.
Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. (Взято с вики).
Тема Agile в 1С уже давно заинтересовала и думал, что в этой статье тема будет немного раскрыта. Ошибся. Половина статьи не раскрывает даже базовых сложностей с внедрением технологии, вторая же зачем-то описывает процесс сертификации. Велосипед сертифицируете?
Считаю тему интересной и с удовольствием почитаю о сложностях внедрения на проектах.
Как уговорить клиента платить за воздух? Ведь отсутствие гарантий и жестких сроков для нашего менталитета не дороже воздуха.
Как составляется договор, какие в нем сроки, гарантии сторон, штрафы и неустойки? Мне не встречался клиент который готов был платить от сюда и до обеда без гарантий.
Как вы обеспечиваете резерв занятости сотрудников? При гибкой технологии у вас может быть проседание в занятости части сотрудников. Как вы с этим боретесь?
Что происходит при увеличении пиковой нагрузки сразу на нескольких проектах? У вас есть резерв сотрудников или вы уговариваете клиента подождать.
Да много вопросов с которыми Вы наверняка уже разобрались. Поделитесь с нами Этой информацией.
(10) Dragonim,
Умею, но отказался от использования ТЗ в 2002 году по нескольким причинам:
Заказчик ЗНАЕТ, что ему надо. К моменту начала сотрудничества с нами по УПП 1.1, этот заказчик уже пользовался услугами фирмы-автоматизатора более 1,5 лет, половина этого срока была угроблена на составление ТЗ, остаток времени на бесконечные безрезультатные доработки УПП 1.1 под особенности учета. Безрезультатные — это когда куплена УПП, а учет ведется на чем попало, только не на УПП, а надо учесть ВСЕ филиалы. В этих условиях нам удалось решить несколько значительных потребностей при помощи Консолидации, а параллельно выполнить доработки в УСО+специфика предприятия и развернуть распределенную ИБ, чтобы пересадить все предприятие на учет в УСО. Однако, через полгода эксплуатации УСО клиент вынужден был отказаться от использования этого продукта (внешняя причина), мы помогли им выполнить необходимые доработки в УПП 1.2 и перенести данные из работающей распределенной базы.
Экономия В РАЗЫ по срокам и стоимости от аналогичных проектов по классической технологии PMBoK IV.
В прошлом году засомневался, вдруг все проекты без ТЗ по нашей технологии, начиная с 2002 стали успешными случайно? При сертификации свои сомнения развеял — об этом был доклад и статья! 🙂
(12) Богатырев Артур,
У этой медали есть 2 стороны. Да, «декомпозиция» (разбиение сложного проекта на простые) — это один из инструментов управления сложностью проекта. Но чем крупнее проект, тем сложнее управлять результатами декомпозиции — вот тут и понадобилась целая система (RMS) и технология, часть которой (систему управления качеством) мы сертифицировали 🙂
(13) Storung,
Чудесно! 🙂 Да, первая часть доклада вводная о гибких методиках и упреках к ним. Естественно, внедряя свою технологию у себя мы с ними столкнулись, но решили (или обошли). Об этом рассказывал на первом Инфостарте в 2012 частично в докладе из которого потом была сделана статья но большей частью в общении со слушателями, во время которого ответил на все заданные вами сейчас вопросы 🙂 Об одном из аспектов организации эффективного взаимодействия с заказчиком рассказывал на другом Инфостарте, доклад так же превратился в статью .
Вторая часть статьи про сертификацию — да, так и задумывалось!
Почти 🙂 Но правильнее сказать, что сертифицировал систему управления качеством собственной технологии управления распределенными программными проектами. То есть, мне удалось сначала выстроить гибкую технологию, которая отвечает на все заданные вами вопросы и сертифицировать ее систему управления качеством — об этом опыте и рассказывал в докладе/статье 🙂
На недавно прошедшем Инфостарте было представлено, как минимум, 3 доклада по использованию гибких методик в проектах 1С и был организован круглый стол с ответами на вопросы заказчикам. Кто не успел задать вопрос и получить ответ во время докладов и круглого стола, успешно подсел за столик к интересующему докладчику на infostart party и допросить 🙂
Да, с многими разобрался и делюсь со всеми, кто посещает конференции Infostart или другие конференции и семинары с моим участием, следите за объявлениями 🙂
(13) Storung, нашел ссылку на видео с IE 2012, доклад и общение со слушателями (чье-то пиратское видео 🙂 Записи кулуарных бесед, естественно, отсутствуют 🙂
Как решаете проблему когда при решении одной мини-задачи по проекту требуется учитывать/принимать во внимание тонкости другой-мини-задачи по этомуже проекту? кто это обеспечивает/контролирует? или Заказчик выступает в роли бесконечного тестировщика?
.
у себя на проекте столкнулся с тем что при реализации разных участков (по сути мини-задачи) — разработчик должен достаточно хорошо представлять структуру/архитектуру системы, заложенные базовые принципы и кучу нюансов Заказчика. По факту я только и делаю что «работаю» тестировщиком — здесь не учли вот это, в условиях такой настройки алгоритм вообще рухнет и т.д. Выбешивает страшно. особенно когда существует еще одна проклдадка между мной и исполнителем с той стороны…
а исполнитель еще говнокодит и оказывается прокладка всего лишь менеджер и не понимает что «ПолучитьЗапрос1(), ПолучитьЗапрос23()» это, мягко говоря, неправильно…
p.s. Сергей, вряд-ли тебе юнит-тесты подойдут при такой ситуации, т.к. сам разработчик должен их рисовать.
(19) да пусть там хоть в цикле запрос выполняется
если меня устраивает функционал и быстродействие — я в код даже смотреть не буду на первых порах (а эти первая пора может быть достаточно длительная)
потому что
был опыт скидывания на сторону мелких разработок раз 4-5 (самому влом ибо тривиально и неинтересно)
не взлетело
один раз в принципе остался удовлетворен
к программисту — претензий не было
как кодер — написал красиво/хорошо, все гуд.. кроме одного…
менеджерам это давать в использование нельзя — потому что просто менеджеров жалко будет как они с этим мучаться будут…
пришлось фейсы и логику взаимодействия междумордия самому сверху накручивать.
очень тяжело быть перфекционистом.
последнее время стал принципиально давить в себе такие порывы.
если исполнители молчат/не возмущаются не стонут — ну так значит и нормуль..
однако плакать хочется когда видишь что можно сделать лучше и это эффективность работы манагмента повысит существенно..
а манагеры — молчат
либо потому что им пофиг
либо потому что не знают (лень думать как вариант) что может быть гораздо лучше…
как-то так…
Подход Белова — вполне оправдан — и это все явственнее видно и как на разработках ПО и так и в других сферах жизни.
Везде идет подвижка причем имхо достаточно явная на оплату не результата, а процесса достижения результата.
Что лично мне не нравится, но ничего поделать с этим видимо нельзя
Так что просто будем принимать как данность/неизбежное зло.
Мне пока явственно непонятно только одно — до какой степени декомпозиции должен дробиться проект/задача — чтобы эти минизадачи Заказчик и Исполнитель могли оценить близко к адекватности.
например — в техпроекте описан требюуемый функционал.
беремся за реализацию.
всплывает типа «это блин целое рабочее место, это дорого/не договаривались итд» — приходится выжимать требуемое (благо взаимодействие с разработчиками считаю удовлетворительным) — начинаешь доказывать что предлагаемый вариант «ручного» выполнения требуемых операций приводит к неприемлемым затратам ресурсов.. так и бодаемся…
как найти взаипопонимание в Белов’ском подходе..?
потому что нет-нет а всплывают задачи/субпроекты когда вариант половинчатого решения — неприемлем. Или все или ничего. А такой субпроект/задача могут быть вообщем существенно трудозатратны…
Я уже практически местаю сидеть кодером и «кодить по ТЗ»
— у вас тут программа падает!
— применяемый вами вариант использования не предусматривался ТЗ…
.
и заи…сь!
по ТЗ наШкодил, бабло получил — свободен как сопля в полете…
(18) CheBurator,
Руководитель проекта с нашей стороны.
В рамках одного проекта это не является проблемой, так как проектом руководит 1 руководитель проектов, способный декомпозировать требования без конфликтов. Если кто-то из разработчиков что-то поломал, выявится на этапе тестирования, будет исправлять («кто последний, тот и папа»). Чуть сложнее, когда решение в одном проекте влияет на решение в другом проекте с другим руководителем, а изменение и тестирование прошло только в одном проекте. Поломка, возможно, обнаружится на стороне заказчика после внедрения. В этом случае применим быстрое разрешение конфликта (откатимся через CVS на предшествующую версию), а поломка будет устранена в обычном порядке, повторное внедрение «связанной» функциональности будет после успешного тестирования на обоих проектах.
Ошибаешься, нам платят за результат!
В нашей технологии, декомпозиция происходит до «задачи». Задача — это относительно самостоятельный объем работы, с которым справится 1 специалист за разумный срок и разумную плату. Например, экзамен специалиста по платформе, по-моему, состоит из нескольких заданий (бух, опер, расчет + что-то теоретическое, так?) на решение отводится около 5 часов. В нашем случае, декомпозиция аналогичного задания, скорее всего, пройдет до уровня объектов — общие объекты и изменение структуры, формы и модули справочников, формы и модули документов, отчеты и все эти задачи раздельно по «компонентам» (или как там, более точный термин для v8?) — вероятно, около 12 задач, общим объемом, сопоставимых с 5 — 15 часами.
О каком взаимопонимании речь? Как нам правильно понять требования? Договориться о сроках и стоимости? Самое сложное, по-моему, кроется в выявлении и правильном понимании требований. Поэтому, мы 1 раз договариваемся: «предоставьте нам возможность, организовать сотрудничество по проекту строго по технологии и вы гарантировано получите требуемую функциональность, в ожидаемые сроки, за приемлемую плату» и все — дальше 1) максимум усилий бросаем на процессы выявления и достижения понимания требований, включая интуицию, творческий потенциал, опыт, накопленный в RMS и личный, 2) оставляем минимум усилий для контроля сроков и 3) освобождаем свою голову от мыслей об оплате 🙂
Кстати тиаки да
Хочу подтвердить сказанное автором гдето выше
За время которое прошло с написания техпроекта до реализации некоторых требуемых функциональностей эти самые функциональности отмерли
Часть по административноорганизационным причинам
Часть по факту изменения обстановки
От части функционала мы временно отказались ввиду его не сильной нужности и трудозатратности реализации
Потому каквидно сто разрабы просио не вытянут
Поэтому подход что нужно то и делаем постепенно приближаясь к требуемому имент место жить
Другое дело что весьма трудно оценить бюджет в который это выльется
Опять же
Хотелось бы конечно посмотреть на написанную вмс
Но боюсь мне ее не покажут
Потому что я злобен
Привередлив
И неадекватен 😉
Извините за кривую грамотность
Писать с айпада еще то извращение
Поубивал бы того кто на рускую раскладку не вынес цифры и знаки препинания
Так и в проектах некоторых
Вроде все в целом работает
Но испытываешь чувство острой неудовлетворенности
Главное то, что практически каждый, кто сталкивался с проектом на год и более полностью согласен с автором в той части, что сделать по ТЗ до конца проекта не получится. На сдаче каждого этапа слышу «Нам все-равно что написано в ТЗ, мы не поняли друг друга, нам нужно вот это и это». Потом начинается длительный этап согласования трудозатрат по новым задачам, изменение требований и все по новому кругу.
И каждому хочется просто получить за выполненную задачу по «факту».
Мы постоянно сетуем на то, что жесткое урезание бюджета приводит к необходимости урезать время и на качество кода. Со всеми вытекающими.
Потому гибкий подход это хорошо, но…
Но не выходит. У клиента есть бюджет и есть резерв. Все что с выше приходится согласовывать с начальником департамента — глабухом/фиником — гендиром и все итерационно и иногда бесконечно.
Согласитесь, что бюджет внедрения быть должен, каждая задача должна быть согласована с заказчиком, иначе как потом доказать, что сделано именно то что он хочет? Работа без жестких требований к конкретной задаче — это рабство 🙂
Да, я еще забыл про тендеры. Зайти на проект без его бюджета просто не получится. Если у вас есть бюджет, сроки и гарантии в подписанном договоре, то итерационный подход будет злом, так как может привести к перфекционистическим идеалам внедрения, что сорвет сроки.
Вы ведь сталкивались с компаниями, в которых внедрения хочет только руководство. Наладить тесное взаимодействие с конечным потребителем — себе же во зло. Они загонят в бесконечные рюши без функционального результата.
Реализовать основной функционал, а потом рюши? А где описано что такое основной функционал? Последовательность и сроки его реализации — ведь это же и есть постановка, которая потом становится ТЗ, Кстати, никто не заставляет написать все ТЗ в начале проекта на год в перед — только для текущего функционального блока.
Но боюсь мне ее не покажут
Потому что я злобен
Привередлив
И неадекватен 😉
(25) CheBurator, тебе именно конфигурацию посмотреть хочется или экскурсию на склад организовать?
(29)
Интересный подход, хотя всех нюансов я пока не понимаю. Например стоит функциональный блок реализовать аренду. Выбрана подходящая конфигурация и началась разработка. Создан новый документ Расчет аренды и все ок. Но потом заказчик говорит, что он «предполагал» что документ будет автоматически заполнять какой-то реквизит на основании данных предыдущих периодов. Т.е. документ корректно работает с введенными данными в этот реквизит. Получить эту информацию можно из отчета. Как отсутствие этого требования может быть отражено в ВПП, если свою функционалность документ реализует.
Для фин дира или начальника отдела — да. Ведь их цель как раз описана Вами — но конечный бухгалтер, кладовщик и пр. хочет «как было в 7-ке» или где-то где было у них еще. Вы можете это называть саботажем, так оно и есть, но это повседневная рутина, которая легко решается согласованным ТЗ.
Ок, внедряем систему финансового учета + казначейство. Раньше бухгалтера создавали платежки и жили счастливо, а главбух, финдир и пр. вешались в конце отчетного периода сводя это в бюджет, формируя международную отчетность и пр. И вот они решили внедрить что-то что бы облегчить свою жизнь. В замен бухгалтера должны связывать документы с плановыми, указывать дополнительные реквизиты и пр. Учиться, а в конце периода выслушивать что и где он ввел не так. Выгод для него (т.е. конечного пользователя) нет, желания делать без стимула — нет. Это может быть саботаж, но скорее всего это будет просто рабочий процесс. ТЗ снимает ответственность по уговариванию конечного пользователя пользоваться реализованным функционалом.
П.С. мы почему-то отошли от темы гибкого планирования на нужно ТЗ или не нужно. Вероятно, это моя вина. И да, я считаю итерационный подход наиболее успешным и неоднократно с этим сталкивался, но, к сожалению, это единичные случаи в мой практике, которые я считаю успешными. И считаю, что ТЗ, ВПП или постановка не противоречат итерационному подходу. Но я так и не понял как уговорить клиента, что это хорошо и обезопасить себя от этого хорошо 🙂
(28) было бы хорошо и экскурсию на склад организовать это в первую очередь
Посмотреть как это работает вживую, посмотреть на живой процесс
Конфигу тоже желательно посмотреть
Но так как я не совсем восьмерочник то мне больше будут интересны общие подходы к реализации функционала и порядок работы или как организована работа аупа склада с конфигурацией
Со своей стороны если будет интерес можно будет на мой склад организовать экскурсию если руководство добро даст
Но сейчас не особо показательно будет так как загрузка очень маленькая и всю динамику не особо видно будет
Вдогонку
Почему хочется посмотреть на склад и на конфигу и на работу — чтобы оценить насколько сильно я у себя на проекте промахнулся
(29) насчет впп -не согласен
Так не годится
Потому что впп может не покрывать требуемый функционал который был согласован и один или два или больше впп могут не выявить ошибку в реализации функционала
И если такая ошибка будет выявлена впоследствии то имхо доработка должна быть осуществлена за счет ранее согласованного бюджета
То есть это то что обычно называется гарантийное сопровождение
Понятно что такой срок гарантийного сопровождения должен быть не бесконечным а разумным для двух сторон
Год в этом случае представляется обоснованным сроком
Конечно многое зависит от темпа использования продукта
При активном использовании гдето и двух месяцев хватит чтобы все бяки повылазили наружу
(31) CheBurator,
С экскурсией пока проблематично, но подумаю, как показать работу — видео, скорее всего, с разрешения заказчика.
(30) Storung,
Нет, для нас это сигнал о наличии скрытого требования. По этому сигналу на этапе анализа мы выявим реальное бизнес-требование (что такого хорошего для бизнеса было в ее 7-ке?), по выявленному требованию создадим ВПП, а на этапе «модель без доработки» предложим альтернативу в новой конфигурации без доработки, либо покажем, «это без доработки», «а вот это мы можем доработать», вероятно, с согласия заказчика чуть изменится ВПП, но критерий приемки будет однозначный.
предложим, доработать решение за плату (дополним ВПП этим «предполагал»). Если клиент будет возражать, доработаем без оплаты (разработчику оплатим), на будущем ВПП будем внимательнее, «предполагал» выявим раньше. В большинстве клиенты мыслят здраво.
В нашем случае у бухгалтер как вводил платежку, так и будет вводить без дополнительной нагрузки и, граница ответственности сохранится в зоне платежного поручения. Доп.реквизиты привяжутся автоматически при вводе на основании утвержденной заявки, прошедшей все круги согласования и попавшей в платежный календарь. Хотя, конечно, функция создания платежки вообще, скорее всего, будет у специалиста казначейства. У бухгалтеров есть много других функций, которые кроме них ни кто не выполнит.
Отказаться от ТЗ? Одно из назначений ТЗ — переложить ответственность за сделанное решение на заказчика, застраховав себя от риска изменения состава требований до момента оплаты выполненных по ТЗ работ либо облегчения процесса согласования доп.оплаты реализации требований, которые появятся сверх ТЗ. Но какой смысл в трате времени на ТЗ, если его все-равно придется изменить или выбросить? ВПП сам по себе тоже не является панацеей, правильно работает только в рамках целостной технологии — правильная декомпозиция, правильный вопрос заказчику при выявлении, анализе и достижении понимания требования и т.д. Убеждать заказчика в том, что «гибкое» — это хорошо? Но это не факт. Я сам однажды воспользовался услугами подрядчиков, декларировавших SCRUM в своей работе, но ребята себя обманывали — «гибкость» внедрили, а про результативность забыли 🙂
(33) CheBurator,
ВПП — это согласованный результат понимания требований. То есть, согласованный функционал — это один или несколько связанных ВПП. Случается, когда разработка стартует в нарушение технологии без ВПП и опыт показал, что это приводит к отклонениям в реализованной функциональности, сроках и/или стоимости, ответственность за нарушение из-за которого случилось отклонение от требуемого результата ляжет на руководителя проектов, стартовавшего разработку без согласования ВПП (наша ошибка, исправление бесплатно для заказчика). Бывает, заказчик ставит требование в формате «добавьте справочник», «добавьте субконто» или «кастрируйте скорее» — мы будем сначала искать первичное бизнес-требование («какую бизнес-задачу собираетесь решить, жениться на еврейке?»), согласовывать его в форме ВПП, чтобы предотвратить «кастрацию» вместо «обрезания». Поэтому, следим за тем, чтобы ВПП покрывали всю функциональность, но без фанатизма, в рамках здравого смысла 🙂
(36) Это нормально и логично.
Вопрос всетаки остался. Если после «сдачи» проекта — выплывают ваши косяки в рамках ранее согласованной функциональности — но эти косяки первоначально не были отловлены ни вами, ни заказчиком — что делаете?
Сколько не читал, ваш подход мне не понятен.
Ваш подход напоминает мне строительства дома без чёткого плана. «Давайте построим небольшой домик для семьи из 4 человек. У них часто гостят друзья и родственники, давайте построим пристрой. У сына новая семья и они хотят жить все вместе, давайте сделаем второй этаж. Вот и у второго сына появилась семья, а давайте настроим третий этаж. К нам переехала бабушка, сделаем для неё надстрой над пристроим. Отцу семейства нужен свой кабинет, не вопрос, сделаем выносной. Забыли балконы на 2 и третьем этаже, сейчас достроим. Печь не может протопить дом из 3 этажей, т.к. была рассчитана на одноэтажный дом, сейчас сделаем центральное отопление. Давление воды не хватает для напора на третьем этаже, построим новую насосную станцию. Прогресс не стоит на месте и появилось центральное горячее водоснабжение, давайте у нас тоже будет. Зимой выпал снег, а крыша не достаточно покатая, под давлением снега дом рухнул к чертям, потому что фундамент рассчитан на одноэтажный дом, потому что фундамент рассчитан на одноэтажный дом, а под завалами остались покорёженное центральное отопление, центрального горячее водоснабжение и насосная станция, благо люди успели выбежать.»
Начиная проект, вы должны точно знать, на что он может быть рассчитан. Как вы это делайте без ТЗ я не понимаю. Ваше ВПП это отдельные части ТЗ, разница лишь в том, что в ТЗ описано как они связаны между собой и почему должны быть именно в той форме, в которой утверждены. Я склонен считать что ТЗ должен быть математически выверен для оптимального функционирования бизнес-процессов компании, а сами бизнес-процессы должны быть частью ТЗ. Для меня ТЗ это не перекладывания ответственности, это стремление к пониманию конечного продукта мной и заказчиком, а так же оптимизация результата во всех направлениях.
(38) покажите пример ТЗ… Не стеба ради, а для обучения.
(37) CheBurator,
Косяки — это ошибки/дефекты? Ошибки/дефекты устраняем за свой счет, даже после завершения договора.
(39) Я бы с удовольствием, но не могу. Коммерческая тайна, а для вычистке необходимо много времени, а после несколько независимых проверок.
(41) Dragonim,
О, да! 🙂 О том, чтобы продать что-нибудь ненужное подороже, купив что-нибудь ненужное подешевле, знает только ваш коммерческий директор, наверное? 🙂
Однажды к нам обратился клиент, который заказал целой консалтинговой фирме описание бизнес-процессов, заплатив бешенные деньги. К моменту нашего прихода, у него на полке красовалось 2 томика, страниц по 500 каждый, за огромные деньги перепиленная вкривь и вкось УПП, из которой с гордо поднятой головой заказчик хвастался: «О! Я тут вижу все задачи по всем пользователям, и 3 прайс-листа!». Попросил, почитать описание бизнес-процессов, чтобы понять хотя бы масштаб требований, но фраза «нет, так как коммерческая тайна» меня несколько озадачила. Что же там такого, кроме «бери больше, кидай дальше, пока летит, отдыхай!» тайного может быть написано? Название фирм? ООО РомашкаНефтеГазСтройНикельСервис? 🙂
(36)
А можете в двух словах описать как будет выглядеть ВПП в случае, например, следующей задачи:
Добавить новый справочник, добавить в документ, добавить новый регистр, добавить заполнение регистра на основании данных + элемент справочника и создать отчет.
В ТЗ я понимаю как это все добавить, но как будет выглядеть ВПП?
Немного не в тему ответа, но все же. Представим, что заказчик говорит, что ему не нужно выводить на форму выбор из этого справочника, а у него всегда будет работа только с одним элементом (кстати, взято из Вашего выступления 🙂 ). У Вас есть ВПП в котором как-то зафиксировано это требование и есть реализация. Через пол года заказчик говорит, что «концепция изменилась» и теперь нужен выбор.
Естественно вы просто добавите и все будет ок. Но что если это будет микро функционал, а макро функциональность через всю конфигурацию. В таком случае Вы просто выставите новые требования на доработку, согласуете новый/новые ВПП, зафиксируете и переделаете? Я правильно понимаю?
Тогда чем это отличается от ТЗ, которое точно так же можно сделать в виде корректировки к конкретному блоку, задаче и ТЗ. А еще лучше просто выпустить новую версию к доп соглашению и сделать то же что и у Вас, но в более формализованном виде?
Т.е. главная фишка «гибкого» подхода в сокращении времени до начала процесса реализации.
П.С. из Вашего же примера: если процесс моделирования и согласования требований продлился бы пол года и за это время заказчик осознал необходимость учета не по одному контрагенту, то это потребовало бы изменения ТЗ. В Вашем же случае придется переделывать всю функциональность корректируя ряд ВПП, подключать новых разработчиков в замен выбывшим, которые выполняли эти доработки и т.д. Или я снова не правильно понял концепцию?
(40) понял
Насколько часты споры с заказчиками по вопросу «кто виноват»?
(39) pumbaE,
Стеба ради… Видел ТЗ, объемом 500 листов. Поразило, что это ТЗ имело 5-ю редакцию, составлялось в течение 1 года без пары месяцев. Печаталось в 10 экземплярах каждая редакция, но поразило, что у заказчика находились люди, которые прочитывали каждую редакцию (бумажный вариант), вносили свои правки (разные в каждую редакцию!). Еще больше, правда, меня поразил факт последующей приемки решения (через год разработки, по-моему). При приемке выявлено было более 1200 ошибок, часть из которых (около 200), исполнителю удалось оформить, как доработки за дополнительную плату (1000 исправляли, как ошибки в течение, по-моему, 1/2 года или больше).
Интересно было бы на подобном заказчике продемонстрировать эффективность нашей технологии, у кого есть такой клиент на примете? Организуйте встречу за вознаграждение в 10% от стоимости проекта по факту 🙂
(36)
На одном проекте таким образом было «прощено» по одной задаче 40 часов, по другой 20, а в общем около 200 часов. Думаю, что закрыв эти недоразумения в пользу клиента, но не в ущерб разработчиков, проблем бы было меньше, но не все готовы принимать такие радикальные решения 🙂
В целом да, но только со стороны привлечения ресурсов, т.е. выгоднее заказчику, а не исполнителю. И плохо представляю применение к группе с фиксированным штатом.
Не буду 🙂 Тут я имел ввиду реализацию функционала по своей сути приближенному к отраслевому решению. Или глобальная переработка существующего функционала под нужды конкретной отрасли. Изменение основополагающего принципа приведет к полному разрушению систему как при гибкой, так и при жесткой методике. Просто в процессе моделирования и составление бизнес-процессов и ТЗ есть вероятность обнаружить или доказать заказчику ошибочность его допущений. Кстати, никто не запрещает сделать «гибкий» механизм, который покроет требования заказчика, но не ляжет при изменении, которые можно предвидеть заранее без ущерба бюджету и срокам. Тут уже вопросы к проектировщику системы.
Про ВПП все-равно не понятно. У нас это называется постановка. Обычно звучит как: реализовать дополнительный разрез ведения учета товаров для нового отчета на основании Остатки на складах. Такие ВПП и правда ставятся, но только на разовые задачи вне проектной деятельности. Тут и правда бюджет ограничен одной задачей и претензии проще решить в пользу клиента.
(34) видео это самый последний вариант
Если другие не удастся
Нет ничего лучше чем вживую посмотреть
Многое становится понятныс
Главная фишка гибкого подхода (нашего, в частности) в его гибкости в отношении ресурсов :-), а именно в наличии возможности динамического формирования и реализации требований. Концепция гибкой методики, по сути, в отсутствии ограничений в исполнительских ресурсах — плати больше, получай больше, когда надо, плати 0, когда не надо. А «быстрый старт» есть и в жестких методиках, в «ТБР», например. В жестких методиках вы действуете в заданных рамках ресурсных ограничений и ограничиваете заказчика при помощи ТЗ. Точнее, заказчик при помощи ТЗ пытается добиться для себя некоторой гарантии, что вы справитесь с поставленными задачами и оговоренный бюджет, а вы, по сути, страхуете себя от изменения требований в сторону превышения ваших возможностей в ресурсах. Хотя, конечно, в SCRUM тоже есть механизм, ограничивающий заказчика в изменениях требований, хотя и на более коротком, чем в классическом проектном подходе, периоде. Хотя, конечно, в части гибкости SCRUM с трудом допускаю, наличие возможности удвоения команды при удвоении объема требований с соответствующей оплатой (одна из причин моего отказа от использования SCRUM :-). Разве что, путем перераспределения ресурсов между проектами, ну да ладно. Надеюсь, разница между жесткой и гибкой методикой стала понятнее? 🙂
(47) как мне кажется например у себя на проете в существенной части вопросов наличие промежуточного звена в виде РП исполнителя было излишним
Вполне бы подошло если бы я напрямую ощался с разработчиками а рп осуществлял бы надзорную функцию по типу чтобы например я не стал бы впихивать программером того что нет в техпроекте
Как вы смотрите на такой вариант?
(48) Storung,
у нас с 2005 года тоже накопилось порядка 580 часов без оплаты от клиентов.
не понятно, что тут радикального?
Не можете 🙂 Очень сложно, придумать — успели написать УТ и выяснили, что надо было БП написать? Или товар стал контрагентами в упаковках торговать? 🙂
Чтобы появился ВПП, еще идем на шаг раньше, чем ваша формулировка. Сначала надо выпытать, чего хотите для бизнеса, что решили дополнительный разрез в остатках? Наверное, первоначальная формулировка «хотим знать, сколько товара от какого поставщика на складе» — и вот тут будет сформулирован ВПП.
у нас рабочие группы динамические — больше требований, больше участников.
(49) evg300183, где-то спрятан вопрос или конкурс на лучший пересказ? 🙂
(51) CheBurator,
В нашей технологии заказчик общается с РП или управляющим (помощником управляющего). Чтобы общаться с разработчиками, над быть РП. Опыт постановки задач программистами вместо заказчика оказался отрицательным.
(42) Рискну таки с вами не согласится в ряде пунктиков. Тут выше писали что «Ваше ВПП это отдельные части ТЗ, разница лишь в том, что в ТЗ описано как они связаны между собой», хотя вы уверяете в обратном. Скажем, вы вот упоминали выше, что таки да, участвуете в проектах с тендером (с определенным бюджетом), производите встречи с заказчиком и т.п. — а это как известно первые ступеньки, без которых нереально составление вообще какого либо плана (ТЗ, бумажки, ВПП, плана «Барбаросса» — нужное подчеркнуть).
Лично мое мнение, что вы на самом деле составляете ТЗ, а в какой форме и под каким именем вы это составляете — это частности, хоть в картинках, хоть в комиксах, хоть в виде мега-ТЗ с красивыми расчетами, хоть в виде некоего демо-примера контрольного (ВПП) и интерактивного. В любом случае вы составляете некую вещь (документ, образец), который служит вам техническим руководством к действию.
Без сомнения, ваше важное отличие и достижение от традиционного ТЗ в том, что вы это делаете в оригинальной форме (применяя итерации, декомпозиции, новые формы общения с заказчиком и сдачи ему частей и доработок и т.п.). Правда какой то революции я все же не вижу. У вас — весьма интересный и оригинальный метод составления технической документации к проекту. Вы реально хорошо экономите на составлении огромного мануала — традиционного ТЗ, который и верно устаревает в процессе. Я бы назвал ваш метод — «динамический итерационный метод составления приближенных ТЗ с применением глубокой декомпозиции и методов эмпирического анализа». Красиво? 🙂 Почти шутка. На самом деле невооруженным взглядом видно, что у вас проделана большая работа по устранению традиционных недостатков работы с ТЗ, тем более, что ряд ваших идей весьма близко похожи на мои мысли.
Я вот с вами согласен, что нельзя делать ТЗ жутко формализованным — это абсурд. С другой стороны, я согласен с позицией, что заказчик на самом деле может смутно представлять на самом деле что ему нужно. Тут большая трудность пояснить заказчику, что его некое желание потребует нехилых усилий (т.е. и средств заказчика), или вообще понять точно что он хочет. Правда, как я смотрю по вашим ответам, у вас очень большой упор на начальную беседу и выпытавание у заказчика точной информации. Но это опять таки хороший тон в составлении хороших ТЗ.
Вы упомянули, что с 2005 года накопили 580 часов без оплаты от заказчика. Даже по самым мега-скромным прикидкам (1000 рублей час) — это более полумиллиона неполученного дохода… А вы так легко «сдаете» все спорные ситуации? Это точно зря. Естественно придется эти спорные ситуации исправлять, но эти ситуации возможно частично оплатил бы заказчик. Как бы это банально и грубо не звучало, но коммерческие разработки заинтересованы в бОльшем оплаченном обьеме.
В остальном точно искренне желаю удачи в развитии своего подхода. А идея с сертификацией — очень умно. Вам бы еще книжку написать и издать на эту тему… 🙂
(52)
то что большинство компаний называют «солидарной ответственностью» и перекладывают свою убытки на исполнителя, ведь именно он не смог донести до руководства часть информации о возможных потерях.
Кстати, вот именно Ваш пример и натолкнул меня на одно воспоминание. Пришел к нам клиент с бухгалтерией с дописанным блоком зарплаты. Ушло на это несколько сотен часов, а функционал не дотягивал даже до КА. А ведь начиналось все тоже с простенького механизма на 40 часов для учета внештатников. Если бы был изучен весь фронт работ вряд ли было бы выбрано такое решение. Я уже не буду описывать процессе перехода на КА этого клиента. Как ВПП и гибкий подход тут помогли бы?
Хотим знать — это уже ВПП или что-то нужно еще?
Так можно сказать про любую фирму франчайзи — они для того и есть, чтобы балансировать нагрузку между проектами. Мне вот не понятно как скоординировать работу 4-6 разработчиков над одним проектом в рамках одного функционального блока, если у нас даже в хранилище ломают функционал друг друга. Если Ваши РП могут все это координировать, тогда Вам однозначно нужно написать статью именно об этом: согласование доработок, контроль версий, тестирование объединенных блоков и т.д. Я видел, что это у Вас есть, но Вы ограничились лишь общими фразами, а это не менее интересная тема и Вам есть что рассказать.
(54) 580 неоплаченных счетов с 2005 г.
Прикинем: 10 лет ( с 2005 по 2014), возьмем 245 рабочих дней в году, = 245дней*10лет*8часвовдень = 19600 часов
580 неоплаченных часов составляют чуть менее 3%, с учетом ч то работает не один человек, а десятка два наверное, то колво неоплаченной работы составляет ~ 0.2% Я считаю что это выдающийся результат, особенно в условиях нечеткой постановки задач.
(55)
тут есть паралельные ветки про гитхабы и прочие инструменты для командной работы, интересно…
(56) CheBurator, минутку, уважаемый, речь идет не об часах работы вообще. А об оплаченных «часах работы подрядчика». Всем известно, что франчайзи (подрядчик) делает некую работу и выставляет счет заказчику, где указано, что на такую то доработку потрачено 100 часов разработки (я грубо утрирую). Эта сумма часов значительно меньше общего числа рабочих часов сотрудников подрядчика.
И кстати, если работает более 1 человека, это еще катастрофичнее, т.к. 1 час выставленный заказчику скрывает 2-3-4 часа работы разработчиков.
Так что 580 часов это не так уж мало. Не скажу что это очень много впрочем тоже. Вопрос в том скорее, что подход таков у автора статьи — не вступать в споры, а исправлять за свой счет. Это неправильно, нужно гибче подходить, а то заказчик может тупо оборзеть.
(58) Главное спокойствие
Я например выступаю в основном заказчиком сейчас
Регулярно выступаю и исполнителем
Залог успешной работы это компромиссы и маленькие бонусы друг другу
Ничто так не выбешивает меня как заказчика как формальный подход к работе
Когда вроде все сделано но лучше бы так не делали
Поэтому гибкий подход Белова с постоянным уточнением требований это есть хорошо
Конечно только тогда когда у тебя нет своих программистовразработчиков
Своими сделать выходит от двух до четырех раз дешевле
Имхо конечно
(54) Богатырев Артур,
Ошибаетесь, Артур. Да, случается, что мы разрабатываем ТЗ, если это требуется в тендере или в другой «клинике» :-), но стараемся на него потратить самый минимум времени и это лишь формальный документ, вплоть до Ctrl#k8SjZc9DxkC+Ctrl#k8SjZc9DxkV и замены заголовка, либо предоставленное заказчиком в условиях к тендеру. Сомневаюсь, что когда-то мы задействуем ТЗ в качестве технического руководства к действию. Максимум, где востребован документ, похожий на ТЗ, это в части интеграционных проектов, где нам приходится договариваться именно о технических деталях взаимодействия с другими ИС и их производителями (Например, «Справочник.Контрагенты.Код <-> Contra.ID (String 20)»).
Нет, для нас важнее содержание проекта. Точнее описано в другом докладе а именно:
И для меня странно, чего, вдруг, обсуждение технологии началось в статье про опыт сертификации СМК? 🙂
Информация информации — рознь. Да, на начальном этапе взаимодействия стараюсь точнее выявить СУТЬ потребностей, но потратить на это минимум времени. Гораздо важнее, понять состав ключевых пользователей заказчика и организовать взаимодействие с ними через RMS.
580 часов без оплаты — это чуть больше 0,6% от фактически выполненных работ за тот же период, какой смысл за них бодаться, это, ведь, множество заказчиков, кто-то остался должен 20 минут, кто-то несколько десятков часов? 🙂
(59) CheBurator,
достаточно спорное утверждение. Сколько человек, какой квалификации надо взять в штат, чтобы написать WMS за 90 дней, от 30 до 60 из которых уже потрачено на тех.проект/ТЗ? Выполнима ли эта задача? Вспомни концептуальную модель усилий Барри Боэма , хорошо объясняющую поговорку «даже самую простую задачу можно сделать невыполнимой, если провести достаточное количество совещаний» 🙂
Могу рекомендовать, кстати, всем книжечку «Управление программными проектами. Практическое руководство по разработке успешного программного обеспечения», автор Марри Кантор.
(62) смотря какая ВМС. Если гибконастраиваемая, адаптивная, с последующим минимальным кодингом и большинством параметрических настроек — то и за 90 дней весьма проблематично если не невозможно. Если же ВМС, ориентированную на конкретный склад или область деятельности заказчика — то не то что вполне реально, а вполне осуществимо.
но это я отвлекся 😉
конечно же — утверждение спорное про «своими силами». «Своими силоами» подразумевает что эти свои силы — есть в наличии. и они достаточно квалифицированы. И будет дешевле и быстрее — хотя бы за то, что отсутствуют прокладки лишние. И присутствует знание, которые всегда может привлечь по «проторенной дорожке».
На выполнение проекта сторонними разработчиками имеет смысл подписываться если в своей фирме тупо нет нужных ресурсовкомпетенций.
Даже тупо взять из области сисадминства. Типа отсосеры — это дешевле. Посчитать на калькуляторах, которые есть не некоторых аутсосерских фирмах — так мой сисадмин тыщ под 150-200 должен получать, по факту — полечает существенно меньше. так и здесь — очень сильно сомневаюсь, что сторонние программисты способны быть дешевле чем свой фикс. Конечно, своего фикса надо пинать, руководить и прочее. Но все равно будет дешевле. Если люди вменяемые. Правда, где таких найти — непонятно…
как-то так.
может, конечно, все неправильно вижу.
(56) > CheBurator, слишком общие допущения и расчет получился ошибочный, хотя всего в 3 раза оптимистичнее фактического
/
ну, какие исходные данные выдали — то и прикинул лаптем к носу.
а то что получилось у меня в 3 раза оптимистичнее чем есть на самом деле — это значит что у вас суммарная часовая выработка за указанны йпериод в 3 раза меньше или количество постоянно работающих меньше чем я предположил (или другие неучтенные данные мною)
«Смешались в кучу кони, люди»
1. Обсуждают систему работу исполнителя с заказчиком в теме про стандартизацию и попытку получения ISO 9001
2. Идёт постоянное перескакивание с понятия «доработка существующего решения» на «создание нового решения с нуля» на «объединение существующих решений» и обратно.
3. Я писал выше, напишу и тут. Я не понимал в чём новшество вашего подхода и, в частности, ВПП в доработке существующего решения, т.к. именно так работают практически все кого я знаю, а многие выполняют задачи по отрывкам мыслей из разговоров и заказчики остаются довольными. Я не понимаю как вы собираетесь использовать ВПП в проекте создаваемом с нуля, т.к. будь у вас хоть 1000 ВПП от всех заинтересованных лиц, пока не будет чёткого понимания (лучше оформленного в письменной форме) основы и логики работы всей системы как единого целого, вы не сможете выдать адекватный результат.
4. Я всегда боялся руководителей которые говорят «я работаю для фана/интереса/результата/добавь_своё, а прибыли у меня на 2/3/4/. ./N месте». Для меня это значит, что такой руководитель может в один прекрасный момент встать и сказать, «я устал, пойду позанимаюсь другим делом, там интересней», или выполнить работу, а на оплату забить, потому что ему не охота бодаться, ведь он выполнял работу ради работы, или он врёт мне в лицо и прибыль у него на первом месте, а весь разговор пустое сотрясание воздуха. Лично мне страшно работать на такого человека.
(63) CheBurator,
Свой дороже! Но стоимость — не первый критерий при выборе «свой/чужой». Заказчик платит за «своего» дороже, так как оплачивает ему за работу, за простои и, даже, за наличие физической возможности, пнуть при случае 🙂
«Свой» нормальный программист работает близко к пределу своих возможностей. Поэтому, удвоение оплаты своему программисту влияет только на увеличение его лояльности к вашей фирме, а объем работ остается без изменений. Если вы заплатили своему прогу в 2 раза больше и результат удвоился, это означает, что этот прог прежде сочковал. Чтобы найти второго добросовестного и квалифицированного программиста, потребуется время на поиск и испытание (1-3 месяца), но 2 программиста в штате не программистской организации потеряют в части производительности. То есть, при удвоении платы выработка возрастет, но, лишь в 1,5 раза в самом оптимистическом случае, а в реальности, скорее всего, останется на прежнем уровне или вообще упадет (зависит от количества совещаний).
Кроме того, «своему» оплата производится от календаря (оклад). Рано или поздно, но среди интересов «своего» приоритетным становится «меньше поработать, но сохраненить стабильность» и, как следствие — «работает, не трожь!», так как процесс программирования тесно сопряжен с процессом создания ошибок, за которые будут ругать и могут пнуть, когда работодателю надоест платить за работу по исправлению ошибок.
Услуги внешнего подрядчика будут дороже, если на подрядчика наехали, «оцените, подпишитесь кровью!». Конечно, кому охота подставляться — тут и ТЗ появится за плату и к сумме будет добавлено 2 — 3 цены для страховки от рисков.
В нашей технологии, стоимость будет сопоставима со стоимостью «своего» за сопоставимый результат, так как ТЗ не нужно, а сотрудничество строго в рамках технологии позволяет обойти риски и гарантирует получение требуемой функциональности, в ожидаемые сроки, за приемлемую плату. Однако, наши возможности выше, чем у «своего» — удвоение требований с удвоением оплаты приводит к удвоению результата! А чтобы мои слова получили вес в разговоре с потенциальным клиентов, была внедрена и сертифицирована СМК. До ее внедрения, у меня был только 1 способ, доказать эффективность технологии — предоставить возможность, воспользоваться ею 🙂
(66) c некоторым запозданием, но отвечу на ряд ваших ответов (пардон за каламбур 🙂 )
Постараюсь быть достаточно кратким.
Вы пишете, что «не составляете ТЗ», но повторюсь, вы на практике его составляете. Просто «ваше» ТЗ не составляется в виде одного или даже группы документов. Вы можете не соглашаться со мной, но ваше взаимодействие с заказчиками оставляет следы? Да, оставляет (не устно же вы общаетесь?). Так вот, любые следы — от видео до простых писем по электронке, как ни странно, это тоже ТЗ (вернее, куски его). Не формализованные часто, но ТЗ. Возможно, у меня неверная терминология, но для меня ТЗ — это все, что описывает пожелания заказчика, процесс работы программы, ответы на вопросы разработчика и т.п. Просто напросто НЕЛЬЗЯ работать без документальных следов, пусть даже эти следы — только электронные.
Про то, что якобы «свои» программисты мол «работает близко к пределу своих возможностей. Поэтому, удвоение оплаты своему программисту влияет только на увеличение его лояльности к вашей фирме, а объем работ остается без изменений.» Прошу прощения, искренне прошу, но это реклама сторонних подрядчиков… 🙂 Я лично всегда считал и считаю что «свои» сотрудники выгоднее подрядчиков.
Во-первых, о занятости. Если организация затеяла проект и привлекла свой Ай-Ти отдел, это значит, что она ДОЛЖНА иметь ресурсы в виде наличия люфта времени у своих Ай-Ти для нового проекта. Если не имеет — это проблема руководства, что приняло неверное решение.
И кстати, идея найти нового программера и ввести его в курс дела — вы пишите 3 месяца. Супер. Вы не уточняете, что поиск хорошего подрядчика, и введение его в курс дела, это, пардонте, тоже не сутки и не двое. 🙂
Далее, очень старая аксиома, что работающий в штате специалист заведомо лучше знает специфику работы предприятия, включая «не совсем официальную» — пардонте, но такие штуки как завязка процессов на ключевых людей в организации, или знание, что при 10 бухгалтерах у нас 8 сачки — никто не отменял. Значит такой сотрудник НЕ будет тратить время (и деньги компании), чтобы «вьехать» в процессы, в отличии от подрядчиков.
Также общеизвестно, что ЛЮБОЙ «свой» сотрудник стоит дешевле подрядчика. При этом если нашего сотрудника мотивировать денежно, то добавится охота и вечером и в выходные работать.
Проблему оплату по окладу вообще решить элементарно — введя систему бонусов и мелких премий.
В остальном все плюсы вашего подхода я сугубо разделяю, разве только третьестепенную заинтересованность в фин-результате не разделяю. Финрезультат — 1-й из 2-х основных стимулов. 2-м является собственно «интерес»
Александр, интересует вопрос «приемлемой платы», которую вы предлагаете обозначить заказчику.
Исходная ситуация: вы согласовали с заказчиком «требуемую функциональность» и «ожидаемый срок», — тут полное взаимопонимание.
Встал вопрос о «приемлемой плате».
Заказчики могут быть разные, с разным жизненным и профессиональным опытом, личностными характеристиками, и представляют компании с финансовыми оборотами, отличающимися на порядки, и It бюджетами, отличающиеся на порядки.
За одинаковую «требуемую функциональность» и «ожидаемый срок» разные заказчики могут предложить суммы от нуля до бесконечности. Кто-то предложит 500 рублей, кто-то 100000 (из них 20000 в конверте).
В это же время у вас:
— может быть недавно реализована очень похожая функциональность в похожей конфигурации, и вы знаете, что функциональность во-многом будет скопирована и себестоимость производства услуги относительно небольшая;
— был опыт реализации подобной функциональности, но в устаревшей конфигурации и требуется время проанализировать, сколько ресурсов займет реализация функциональности в текущей конфигурации;
— не было опыта реализации подобной функциональности.
В общем, в ряде случаев вам сразу будет неизвестна «ваша» оценка функциональности (надо будет потратить время, оценить).
А когда «ваша» оценка все-таки появится, то сравнения ее с обозначенной заказчиком «приемлемой платой» для разных заказчиков могут давать совершенно различную маржинальность.
Если «приемлемой плата» больше, чем вы ожидаете, предлагаете ли заказчику сделать дешевле или просто радуетесь и работаете ?
Если «приемлемой плата» меньше, чем ожидаете, предлагаете свой вариант или не работаете, или пытаетесь договориться об изменении других параметров («требуемая функциональность» и «ожидаемый срок») ?
Не мешает ли запрос «приемлемой платы» финансовому планированию в компании ? Вы же планируете, наверное, сумму, которую компании требуется заработать за месяц.
(70) Wooster,
Больше скажу, оценка всегда не известна. Варианты устранения неопределенности:
1. Оценить (мы или заказчик) без решения.
2. Решить, оценив по факту (наш способ).
Если при передаче заказчик высказал отклонения в отношении стоимости полученного в п.2 решения, вероятнее всего, решение было сделано с отклонением от технологии. Корректирующие действия проводятся в зависимости от выявленной причины.
Мы планируем результаты работы в часах, по каждому клиенту. Если план выполнен и эти часы отработаны в строгом соответствии с технологией, то финансовый результат приемлемый. Если план не выполнен, находим причину и проводим корректирующие мероприятия, влияющие на «требуемую функциональность, в ожидаемые сроки». А если фин.рез оказался не приемлемым, то корректирующие мероприятия могут коснуться цен на услуги.