Опыт практического применения методики BDD на 1С. Написание сценариев
Предпосылки
Год назад наша компания находилась в классическом революционном состоянии, но с точностью до наоборот: верхи не хотели жить по-старому, а низы не могли жить по-новому. И вот я как один из представителей верхов находился в поиске «серебряной пули», которая бы позволила нам перейти из естественного состояния типичного 1С-Франчайзи (когда «неуязвимые чувачки» (C) @zevvssibirix говорят заказчикам: «мы сделали то, что вы от нас хотели, а то, что вам не нравится результат – это не наша проблема», когда о результате изменений в рабочей базе клиента мы узнаём утром от разъяренных менеджеров, у которых недостаточно прав для исполнения их обычных операций и т.д. ) в новое технологичное и управляемое состояние. В итоге мы начали обширную кампанию по организационным и технологическим изменениям в том числе и с привлечением сторонних специалистов, а поскольку нет предела совершенству – то кампания эта продолжается и, я надеюсь, будет продолжаться достаточно долго.
В этой статье я хотел бы рассказать о нашей попытке начать вести разработку на 1С с использованием методики BDD – поскольку данная методика (среди прочих технологических и организационных новаций) взята нами за ориентир, как внутренне присущая DSL-языкам (подробнее об этом здесь).
Немного о BDD для затравки
Что мы знаем про BDD? Знаем, что человек по имени Дэн Норт придумал эту методику, как эволюционное развитие TDD, и есть несколько его статей на эту тему (Введение в BDD и Что за User Story ). Знаем, что есть проект Cucumber, Aslak Helesoy и язык формального описания требований Gherkin, есть многочисленные фреймворки для высокоуровневых языков. С Божьей милостью теперь есть и фреймворк для 1С от проекта «SilverBulleters» - VanessaBehavior. Подробнее о BDD можно почитать на хабре или спросить у гугла – методике уже больше 10-ти лет, так что информации накопилось достаточно.
Чего мы не знаем про BDD? Здесь самое интересное. Дело в том, что когда люди говорят о «методике BDD» - они чаще всего говорят о «мечте-идее о BDD». Это как «коммунизм» в прозе Андрея Платонова: все о нём говорят и к нему стремятся, но имеют весьма смутное представление о том, что же это такое. Постараюсь объяснить, в чём тут сложность. Адепты «бихавиоризма» легко пишут кейсы сценариев для калькуляторов и банкоматов – ну что может быть прозрачнее:
Идеально, не правда ли? Разработка калькуляторов реально вышла на новый уровень…
Dark side of the moon
А теперь давайте перейдём на тёмную сторону луны – поговорим о разработке на 1С. Я какое-то время разрабатывал на 1С, и отчётливо помню, что когда мне было одиноко – я всегда разрабатывал калькуляторы или программировал «змейку» на 1С, и всё время меня мучал вопрос «как это сделать по-правильному?». И как назло от этого увлекательного занятия меня зачем-то отрывали заказчики и требовали странного: каких-то аналитических отчётов, новых документов, изменения существующих документов, сервисных обработок, интеграции и тому подобных «низких» вещей. И я старался поскорее расправиться с этой скукотищей, чтобы вновь с головой погрузиться в загадочный мир калькуляторов и «змеек». Знакомая ситуация? И я понимаю, что мои сотрудники в основном также воспринимают мир. И я должен к ним прийти и сказать: «Ребята, прозрейте! Всё, что вам казалось рутиной и скукотищей, всё что вы делали на скорую руку и сбрасывали тестировать заказчику, всё вот это вот тоже можно делать по-правильному!» Сначала они говорят: «Опять барин на хабре сидел…» Потом видя, что я не отстану: «Сейчас отчётик на компоновке добью – и попробуем». Я им даю мануалы про калькуляторы и банкоматы, они кивают, курят – потом приходят и задают логичные вопросы:
- BDD – прикооольно! Мне тут заказали сделать документ «Отчёт о рабочем времени» в УТ 11, чтобы менеджерам можно было отчитываться о проделанной работе. Как мне это сделать по BDD?
- BDD – крутяк! Мне тут заказали номенклатуру из Excel с картинками загрузить. Как мне это сделать по BDD?
- BDD – отпад! Тут клиентик попросил товары из одного заказа поставщику выборочно перекинуть в другой, причём у него там всё разбито под заказы клиентов, а перебрасывать он хочет сводно по номенклатуре. Как мне это сделать по BDD?
Про товарища, также восхитившегося BDD, и предложившего «обменять УТ 11 с самописным сайтиком одного клиентика», я не буду ничего писать. Просто не буду и всё.
Сценарий «Отчёт о рабочем времени»
Что может быть проще – для начала нужно написать сценарии использования. Это действительно просто (на самом деле - нет). Ну вот возьмём задачу с документом. Начнём!
Хм… Тогда что? По теории сценарии должны воплощать критерии приёмки. То есть какой конкретный результат должен быть у данного действия? Я как программист честно говоря не знаю. На мой взгляд (как программиста) конечный результат – это записанный документ с информацией менеджера. А вот какой результат ожидает менеджер? Кто об этом должен думать? Программист 1С? Отложим этот вопрос до лучших времён, и вдохновившись статьёй Сергея Георгиевича, включим режим бизнес-аналитика. Итак, предположим документ введён. Что будет дальше с ним делать менеджер? Сам ему предложу. Слушай, менеджер, вот ты отчитался за неделю, каждый день вводил эти долбаные отчёты, и вот пятница, потом выходные пролетели в пьяном угаре, и вот понедельник, башка болит, всё в тумане. Что тебе поможет вспомнить всё? Конечно отчёт о прошлой неделе! Это же очевидно. Строим отчёт по дням и вспоминаем, вспоминаем, вспоминаем… Это великолепно!
То есть сценарий должен заканчиваться отчётом. Менеджер вводит документ за документом, чтобы в итоге построить ретроспективный отчёт:
В принципе неплохой прототип сценария… Показываю менеджеру – он счастлив. Как бизнес-аналитик я отработал. Возвращаюсь в режим программиста. Смотрю на сценарий – и он мне не нравится. Он мне не нравится, потому что мне непонятно, что надо делать. Какие должны быть реквизиты у документа, какие из них обязательные, какие нет, какие кнопки должны быть, может нужно какие-то документы привязать (письма, контакты, заказы), про отчёт вообще непонятно. Ну ладно, по ходу додумаю…
Скажу сразу чего не хватает этому сценарию: конкретики. Должен быть конкретный пример, что и в какие поля вбивает менеджер, и какие данные в отчёте он в результате видит.
Cценарий «Загрузка из Excel»
Ну это каждый 1С-ик делал. Сейчас разберёмся. Пишу:
Очень информативно, правда? А что может ещё расписать бизнес-аналитик для такого сценария, если поведение пользователя в системе будем именно таким? Я как программист должен внести исправления в исходный сценарий, чтобы как минимум указать структуру Excel-таблицы, из которой буду загружать данные. Заметьте, что дальше я как программист предпочту выполнить проверку прочитанной из Excel-файла информации. То есть мне нужно сделать некую промежуточную таблицу, в которую загрузится содержимое файла Excel. И таким образом я проверю, что в файле тоже самое, что и в моей промежуточной таблице. Потом я должен создать номенклатуру и проверить её создание. И это всё я должен выразить на декларативном языке описания требований. В этот момент программисты обычно начинаю роптать. Они говорят про самодокументирующийся код, про то, что запрограммировать будет быстрее, чем писать этот сценарий, и так всё понятно, и вообще Gherkin не нужен…
Итак, обработанный программистом набор сценариев:
Первый:
Второй:
Третий:
Четвертый:
Ну вот это уже сценарии для нормальной разработки! Тут и сторонники TDD скажут, что это похоже на тестовые наборы с ассертами, ну и вообще имеет право на жизнь.
Но и тут есть нюансы. Например, я как бизнес-аналитик смотрю на этот сценарий и спрашиваю: «а это вообще о чём?» Что это такое? «Ну как же?» - отвечу я как программист – «это же тот самый сценарий загрузки номенклатуры, только улучшенный!» Но бизнес-аналитик покачает головой и скажет: «мне будет трудно донести это клиенту, слишком много технических подробностей». Ну и я как зануда добавлю: «а в чём здесь собственно поведение? За этими деревьями строк и таблиц совсем не видно бихавиорного леса». То есть фактически это превратилось в тестовые наборы на Gherkin, а совсем не в описание поведения пользователя. Более того, когда бизнес-аналитик договаривался с клиентом – то зафиксировал договоренности в первоначальном сценарии, а в качестве базы для реализации будет применяться совсем другой сценарий. Я как клиент не могу быть уверен, что в ходе трансформации не было утеряно само зерно моей хотелки – и принимая работу, я как клиент буду неприятно удивлён.
Если на претензию об избыточности технических нюансов можно ответить «интегральным сценарием» либо многоуровневым (вложенным) сценарием, то что делать с бихавиорным дуализмом или дуалистичным бихавиором мы ещё для себя не решили.
Интегральный сценарий даёт возможность ссылаться на другие сценарии feature-файла, либо экспортированные сценарии других feature-файлов в той же папке и вложенных в неё:
Многоуровневый (вложенный) сценарий позволяет превратить сценарий в древоводиную структуру с использованием тэга @tree:
В этом случае текст «Чтение данных из файла Excel» и «Проверка прочитанных данных из Excel» - не являются исполнимыми шагами сценариев, а всего лишь узлом дерева – конкретные шаги расположены на уровень ниже.
Вот как это выглядит в VanessaBehavior:
Резюме
Какие вопросы я хотел осветить, а точнее – поднять для обсуждения:
- Внезапно BDD – это не о программировании, а о бизнес-анализе. Кто из ваших сотрудников будет этим заниматься? Программисты, которые мыслят объектами метаданных? Методисты, которые мыслят жёлтыми книжками?
- Какой должна быть степень детализации проработки сценария бизнес-аналитиком, и где та грань, когда сценарий будет уже понятным программисту, но ещё не потеряет своей семантической нагрузки?
- Как бизнес-аналитику писать сценарии, чтобы программист реально ими пользовался, а не выбрасывал их и переписывал на такие, чтобы ему удобно было разрабатывать?
- Как объяснить бизнес-аналитику, что ему больше не надо описывать функционал, а нужно описывать поведение пользователя? Не превращать каждый сценарий в описание внутренней логики программы при нажатии кнопки, а фокусироваться на критериях приёмки.
- Насколько это корректно заставлять человека-непрограммиста описывать требования заказчика с использованием формального языка? Если роли БА и программиста выполняются одним человеком – то проблем нет, а если у нас проект и команда, тогда как?
- Как повлияет на скорость разработки/внедрения составление сценариев бизнес-аналитиком до программирования?
- Как использовать BDD на проектах внедрения, когда львиная доля – это типовой функционал 1С? Обкладывать сценариями типовой функционал?
Темы, которые я хотел бы затронуть в следующих статьях этой серии:
- Как поставить применение BDD на поток в проектах внедрения 1С?
- С чего начинается сценарий? Предварительная работа с требованиями заказчика.
- Как организовать регрессионное тестирование внедряемых типовых конфигураций с использованием сценариев поведения пользователей.
Отдельно хочу поблагодарить за содействие в написании статьи:
@allustin – главный идеолог команды «Серебряная пуля»
@Pr-Mex – автор фреймворка Vanessa-Behavior
Пообщаться со всеми нами на тему "BDD и 1С" можно здесь.
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Тестирование QA Разработчик 1С:Предприятие 8 Бесплатно (free)
Когда полная сборка автотестов занимает полчаса, даже небольшая автоматизация может изменить рабочий процесс. Рассказываю, как Python-утилита Phase Switcher постепенно превратилась в KOT for 1C — open-source расширение для VS Code. KOT 3.0 объединяет в одной рабочей среде библиотеку шагов и сценариев, IntelliSense, поддержку СППР и самостоятельных feature Vanessa Automation, исследователь форм, запись действий и управление выполнением через MCP. В статье — история разработки проекта от небольшой Python-утилиты до расширения для VS Code, практические примеры, неудачные эксперименты и решения, которые помогли инструменту прижиться в нашей команде.
02.11.2026 344 alexiosus 0
Тестирование QA Бесплатно (free)
Резкий рост числа пользователей, консолидация систем или миграция в облако требуют заранее понять, выдержит ли инфраструктура новую нагрузку. Рассказываем, как с помощью LLM команда за 16 недель подготовила и провела нагрузочные тесты для шести баз: автоматизировала анализ технологических журналов и журналов регистрации, формирование реалистичных сценариев и создание обработок для «1С:Тест-центра» и JMeter. Показываем, как оркестратор, AI-агенты и MCP-серверы помогают сократить объем ручной работы, а также объясняем, почему контроль со стороны 1С-эксперта по-прежнему остается обязательным. Разбираем архитектуру решения, уже работающие инструменты и направления дальнейшей автоматизации нагрузочного тестирования.
31.10.2026 412 gabrielyants 0
Инструментарий разработчика Тестирование QA Разработчик Стажер 1С 8.3 Абонемент ($m)
Проверила пять пакетных команд платформы 8.3.27 на контрольном расширении Нано-УТ: они обнаружили 4 из 28 заложенных пунктов. В набор входят ошибки применимости, предупреждения и сведения для ручного разбора. Проверка XML-выгрузки отметила все 28 пунктов и 15 из 15 на похожем слепом наборе. Показываю журналы, ограничения и сценарий обновления основной конфигурации. Прилагаются инструмент с 69 тестами и материалы опыта.
7 стартмани
28.10.2026 299 Ninel_S 2
Инструментарий разработчика Мобильная разработка Тестирование QA Разработчик 1С 8.3 Абонемент ($m)
Скрипт form_diff_mobile.py сравнивает две выгрузки конфигурации 1С и показывает, что в формах удалено и переименовано, где на это ещё ссылаются и какой код попадает в мобильные контексты. На «Нано-УТ 2.0» сделано 13 изменений форм: платформа 8.3.27.2130 отметила 7, в остальных шести промолчала, и в четырёх из них скрипт нашёл обращение к удалённому элементу, строку с прежним именем формы, смену директивы или выход формы из мобильной области. На чистой УТ 11.5 сравнение с копией дало 0 находок, а с копией с пятью правками ровно семь. В архивах скрипт, 74 теста, стенд, чек-лист выпуска, журнал выпуска и скрипты опытов на платформе.
7 стартмани
27.10.2026 274 Ninel_S 0
Тестирование QA Разработчик 1С 8.3 Абонемент ($m)
Прогнала через 1С 8.3.27 и валидатор .NET 21 файл XML по одной схеме: базовый пример и типичные отклонения. Вердикты совпали в 20 случаях (у .NET включены предупреждения), дата без времени дала расхождение. В архиве - схема, тесты, закреплённая версия учебной базы и исправленный сценарий проверки, включая выгрузку и обратное чтение 30 продаж.
1 стартмани
26.10.2026 273 Ninel_S 0
Рефакторинг и качество кода Тестирование QA Системный администратор Разработчик 1С 8.3 Абонемент ($m)
В базе 1С на PostgreSQL копятся индексы, которыми никто не пользуется: их создаёт флажок «Индексировать» у реквизитов или их добавляют вручную. Каждый такой индекс замедляет запись: в опыте на тестовой таблице восемь лишних индексов сделали вставку 300 000 строк в четыре-шесть раз дольше. Скрипт на Python смотрит статистику PostgreSQL и показывает, какие индексы ни разу не использовались и какой реквизит 1С их создал. На нашей конфигурации «Нано-УТ» он нашёл четыре ненужных индекса документа и один дубль, добавленный вручную. После того как я сняла флажки и обновила конфигурацию, индексов стало 227 вместо 234, данные не пострадали. В архиве скрипт, запросы и примеры.
5 стартмани
23.10.2026 436 Ninel_S 4
Рефакторинг и качество кода Тестирование QA Разработчик 1С 8.3 Абонемент ($m)
Скрипт, который должен был проверять код 1С в Docker, на деле проверял только, что файл не пустой: из 11 модулей с ошибками он пропустил все. Я переписала проверку и сравнила её с самой 1С на тех же 11 модулях из нашей конфигурации «Нано-УТ». Новый скрипт нашёл незакрытые «Если», процедуры и скобки в 10 случаях из 11. Вызов несуществующей процедуры находит только сама 1С. В архиве скрипт, файлы для Docker, примеры с ошибками и журналы проверки.
5 стартмани
23.10.2026 419 Ninel_S 4
Рефакторинг и качество кода Тестирование QA Разработчик 1С 8.3 1С 8.5 Абонемент ($m)
Генератор Form.xml из JSON прошёл тесты, но Конфигуратор сначала отверг форму, а после исправления типа без сообщения об ошибке потерял 6 элементов из 10. Ищем причины и делаем проверку через платформу. Исправленный генератор испытан на 8.3.27.2130 и 8.5.1.1302: пять форм конфигурации, веб-клиент, стандартные команды из JSON, запись и проведение. В архиве Вы можете получить исходники, примеры обработки, справочника, документа, отчёта и регистра, тесты и журналы прогонов.
5 стартмани
22.10.2026 375 Ninel_S 0
1. Какое у вас покрытие кода тестами? Все-таки написание тестов для проверки ряда алгоритмов будет занимать приличное время, особенно по началу. И не всегда возможность автоматического воспроизведения тестового сценария оправдана...
2. Как вы организовываете базу для тестирования? Сами набиваете необходимые данные на чистой базе? Или есть своя база для каждого теста?
1. тестов в BDD нет. Тесты в TDD - соответственно и покрытие считается другое.
2. раз тестов нет - то нет и базы для тестирования. Есть база для проверки поведения... и внезапно, заполнение базы, это блин также поведение системы. Она же не из воздуха заполняется.
это если коротко.
Ответ на второй я попробую оформить отдельной статьёй, чтобы так сказать не расплескать.
Коллеги, работающие по BDD, пожалуйста, хватит холивариать! :-) Вы тратите время пытаясь объяснить свою позицию паре откровенных скептиков, это бессмысленно, но про это пишут уже в книгах по психологии))
Полезный выхлоп будет намного больше если вместо этой дискуссии вы напишите еще пару таких же вдумчивых статей, как эта. И Вы уже пообещали в комментах:
1.Success story. Это нужно чтобы те кто уже верят в эти методики - могли "продать" их своим коллегами-внедренцам, чтобы они начали их использовать.
2.Важный вопрос о подготовке исходных данных для тестирования. Для меня лично - это самый сложный открытый вопрос и камень преткновения для перехода на BDD.
//честно пытался прочитать все комменты, потому что говорят "в споре рождается истина". Эмпирическим путём установил что после первых 50 комментов в споре рождается только продолжение спора. Предлагаю завязывать
Дам свои варианты ответов на поставленные вопросы, кратко.
1.Внезапно BDD – это не о программировании, а о бизнес-анализе. Кто из ваших сотрудников будет этим заниматься? Программисты, которые мыслят объектами метаданных? Методисты, которые мыслят жёлтыми книжками?
BDD начинается в отделе аналитики, потом идёт в отдел разработки, потом идёт в отдел качества, потом идёт к техническим писателям (для создания документации). Заниматься будут все )))
2. Какой должна быть степень детализации проработки сценария бизнес-аналитиком, и где та грань, когда сценарий будет уже понятным программисту, но ещё не потеряет своей семантической нагрузки?
Фича файл проходит несколько итераций на своём пути.
Сначала он содержит минимум деталей (И документ записался, И документ провелся). Затем она обрастает нужными деталями. Нужными как для бизнеса, так и для технарей.
Где находится баланс - как обычно, где-то посередине. Команда его найдёт с опытом.
3. Как бизнес-аналитику писать сценарии, чтобы программист реально ими пользовался, а не выбрасывал их и переписывал на такие, чтобы ему удобно было разрабатывать?
Программист должен их не выбрасывать, а уточнять до "готовности".
4. Как объяснить бизнес-аналитику, что ему больше не надо описывать функционал, а нужно описывать поведение пользователя? Не превращать каждый сценарий в описание внутренней логики программы при нажатии кнопки, а фокусироваться на критериях приёмки.
Надо сказать ему: "Коля, теперь тебе надо описывать поведение пользователя!"
А если серьёзно, то это вопрос обучения и готовности человека к изменениям.
5. Насколько это корректно заставлять человека-непрограммиста описывать требования заказчика с использованием формального языка? Если роли БА и программиста выполняются одним человеком – то проблем нет, а если у нас проект и команда, тогда как?
Gherkin - язык, конечно, формальный - но очень простой. Он так и был задуман, чтобы его понимали все участники процесса.
6. Как повлияет на скорость разработки/внедрения составление сценариев бизнес-аналитиком до программирования?
Классический вопрос по скорости разработки, при использовании методик BDD, TDD и т.д.
На мой взгляд, корректней говорить о циклах разработки.
7. Как использовать BDD на проектах внедрения, когда львиная доля – это типовой функционал 1С? Обкладывать сценариями типовой функционал?
Отличный вопрос. Было бы круто, если бы типовые конфигурации были покрыты фича файлами из коробки!
Итого: очень круто видеть 1С-Франчайзи, который применяет такие технологии в реальности! Браво!
Может быть поэтому Вам как практикующему разработчику статья показалось "бизнес-аналитической" заумью - она действительно не о программировании.
У меня встречный вопрос: а как у Вас ставятся задачи на разработку, в каком формате пишутся спецификации, как происходит приёмочное тестирование? Это те вопросы, которые я бы хотел обсуждать в рамках этой статьи.
Главная проблема - это низкий уровень культуры бизнес-анализа. Возможно я скажу крамольность, но в 1С-Бизнесе люди такого класса вообще редкость. Есть РП, есть методисты, есть программисты. Есть водопад с тоннами ТЗ и техпроектов, есть ТБР с анкетами и интервью. А вот люди, которые могли бы мыслить в терминах "требование клиента - критерии приёмки - разработка - тестирование" есть ли они? Люди, которые практикуют целеориентированное проектирование?
Сейчас же я наблюдаю другую тенденцию: бизнес не готов платить дважды. Требуя всё ту же скорость решений, они фильтруют запросы в сервис-деске по типу "Ошибка" и говорят - за это мы платить не будем, мы за это уже платили, а вы своими "обновлениями" это взяли и испортили.
И я понимаю, что "как раньше" уже нельзя, и у меня вопрос: как нам обеспечивать высокое быстродействие, не теряя в качестве? Я вижу так, что только за счёт повышения технологичности и максимальной автоматизации рутинных процессов. Поэтому неизбежно нужно обращаться к общепринятым IT-практикам. Адаптировать их к 1С-реалиям и применять.
Когда мы сейчас говорим бизнесу о том, что у нас есть монитор качества разработки и мы не допустим в production изменения, если в allure не светится радужный единорог - они смотрят на нас умными глазами и говорят: это очень интересно.
Если Вы знаете более простой и дешёвый путь - было бы интересно услышать Ваше мнение. Я в данном случае достаточно прагматичен, если есть более оптимальное решение из соотношения цена/качество - тогда конечно Agile, BDD, CI, allure всё это зря.
Я бы с удовольствием ходил бы и на gerkin писалформализовывал поведениетребования
Только кто ж мне даст программера который напрограммит это все? Итого сам себе и бизнесаналитик и программер - причем и первый и второй так себе
Хорошо когда новый проект с нуля и можно попробовать запилить все по правильному с самого начала, а как быть если это не проет с нуля а постоянный процесс подгребания и устранения и новых фич внедрения?
Проблема в ресурсах. Както я не вижу готовности мелкосреднего бизнеса на отдел одноэсников из трех человек фот давать больше чем на отдел продаж из шестисеми человек. Может я в неправильных конторах работаю.
Франчей поубивать бы
Вот эти описанные технологии как раз бы проталкивать как обязательный стандарт разработки у франчей, а то у мну лавочник сорок штук отдал и по факту я уже три глобальные ошибки выловил - и что делать? Самому все писать? Умру...
Понятно что здорово
Понятно что имеет смысл это только когда отдел разработки наверное человек пять
А что делать в мелких компаниях?
Где извратов вагон а ресурсов коробочка? Смайл
Непонятно!
Смысл использования новой технологии конечно был не в этом.
Это было нужно для закрытия вакансии носильщика табуреток.
на 32 минуте 53 секунде.
Надеюсь теперь можно расслабиться и продолжать работать по-прежнему ;) Ждем нового сотрудника в нашем уютном офисе.
А если серьезно : а как вы считаете потери , вызванные бесплатной работой или замедлением скорости поставки ценности заказчику?
Сколько бесплатной работы делается потом, через месяц или два после выполнения нечеткого пожелания чтобы все заработало?
Сколько стоит потеря доверия от заказчика? Рынок то у нас гадски сжимается. А нового привлечь вместо этого разачаровавшегося это дорого очень. С ним и поговорить надо, и посмотреть что за бизнес, и рассказать какие мы классные. А в это время можно было 10 старым лояльным уже много чего хорошего предложить. Но не получается - им же косяки закрываешь свои же прошлые.
Ну и давайте теперь вот эти суммы потерь сравним с:
1. стоимостью задавания вопросов: "Чтобы что?", "как вы будете проверять работу?" , "как я пойму что я сделал работу правильно?"
2. стоимостью оформления требований заказчика в виде карты целей и пользовательских историй
3. стоимостью внедрения методики проверки качества этих историй
Если 1+2+3 > потерь - то конечно нафик это все нужно.
Если меньше - ну есть повод подумать.
Ну и уточните какой бизнес должен выиграть: бизнес разработчика(программиста), бизнес клиента, бизнес организации ...
(28) извините, но 1С - это фирма, её внутреннюю подноготную пусть сам и публикуют (что они уже и начали делать на Хабре). Что касается "мира 1С" - то тут вопрос лучше задавать самому себе, если считаешь себя его представителем. Я ваши слова читаю как "теория проектирования , моделирования, коллективной разработки мне никак не помогла, поэтому ну её нафиг".
Ещё раз: я задал конкретные вопросы, верно? Верно. Вопросы отнюдь не риторические. Вот и просьба отвечать на них в меру своего имхо, а не передёргивать и не выкручивать в сторону, кому что помогло. Я про себя и свой опыт ничего не писал, я задал вопрос. Ответьте или не тролльте.
.
Заказчики лично звонят, пишут, говорят:
* так дальше нельзя
* у нас какой-то дурдом
* можно по другому ?
из последнего письма "Нас задолбали наши 1С-ники, мы готовы их всех нахер уволить или лишать зарплаты за баги в продуктиве (с)" (прямая цитата)
мы говорим можно и показываем как - высылаем материалы
* дальше мы подписываем NDA - соглашение о неразглашении исходников, доступов и методических материалов.
* дальше начинается классический проект "Имплементация инженерных практик"
опять же как показывает практика заказчиками могут стать только 2 типа людей:
* люди которые понимают сколько они сейчас теряют на времени простоя систем на 1С и на времени возврата на доработку
* люди которые понимают что ИТ издержки нужно постоянно снижать, за счёт автоматизации процессов производства ИТ.
Как видно - основными заказчиками в итоге становятся "Руководители ИТ", которые либо только пришли в компанию, либо инициировали процесс оптимизации внутренних ИТ процессов.
О чём кстати Денис тонко в заголовке намекнул - он то один из руководителей, причем как видно технический.
Результатом таких проектов становится постановка процесса "Автоматизированный релиз-менеджмент" внутри ИТ отдела. Там же не только BDD, а например code-review, TDD, CI-CD и т.д., и внезапно DevOps.
.
Но на Инфостарте мы не торгуем, я старательно воздерживаюсь от любой рекламы каких-бы то ни было услуг. Поэтому и не хочу чтобы дискуссия перетекла в разряд "Продайте нам BDD"
И вообще - публикация успешных историй и остальная маркетинговая шелуха мне непонятна. Вы же понимаете надеюсь что "бог в деталях" ?
Вообще фраза "история успеха" - это формулировка рекламщика или продажника. Бррр....
Мне вообще странны такие формулировки - вы искренне считаете что все люди которые активно работают тут:
*
и тут
*
Это прям гики и используют это потому что им так хочется ? И вообще они все ужасно неээфективны и неуспешны ? И работают они все в "серебряной пуле" и вообще...
Если честно - в этом году я принципиально против публикаций отзывов о реальном внедрении и реальных результатов. По двум причинам:
* текущие клиенты (платные) и участники сообщества должны собрать "все сливки" с технологии - чтобы те кто не верит и ждет историй успеха, были в числе "догоняющих". В теории продаж это называется "вызвать чувство потери" - пусть оно будет и у Вас.
* холивары неэффективны - это уже доказано. Потеря времени составляет множество тысяч рубликов - и не улучшает ни инструментарий, ни процессы.
Что касается холиваров - я так понимаю ни (35) ни (36) не поняли главного.
Автор статьи насколько я помню является одним из руководителей производственного процесса внутри 1С:Франчайзи. Франчайзи коллеги !!!
И они уже работают по BDD.
И это уже история успеха - "Франчайзи работающий по проектам 1С с помощью инженерных практик"
И так на всякий случай напомню - вот эта вот фича, не абстрактная
Там светится наименование контрагента который внедрял УТ ;-) (0) Извини Денис - но вы сами спалились. Неужели никто не обратил внимание на абревиатуру ОМПК ;-)
Но на сегодня мне удобней сказать следующее:
* (35) BDD - это конечно же умозрительная технология, никому не помогающая. Нигде не работает. И вообще она не нужна.
* (36) 1С - компания которая ничего не улучшает, все у ней падает, платформа отстой. Эргономика плохая. И вообще 1С не нужна - всем срочно писать ERP на PHP.
Для интересующихся 2 новых скриншота из того чем мы сейчас заняты в части эффективности производственных процессов
* автоподстановщик шагов для VSCODE - для более удобной коллективной разработки
* математический расчёт технического долга - для планирования задач по оптимизации
Тут некоторые с удивлением узнают Windows оказывается платная программа.... что уж говорить....
Связно изложено и последовательно
Ставновится яснее
Как все происходит у меня
Есть некий посыл а типа сделайте вот типа такого или тут у вас плохо
Ладно, иду пытаю одних что такое хорошо
Выслушал
Сформировал мнение
Иду пытаю вторых
Ибо все пробоемы на стыках
Выслушал
Сформировал мнение
Имею два мнения
Они друг с другом дружат очень плохо
Хожу как передаст и склеиваю лоскуты в одеяло
Вроде выстроилось илеологически
Набросал в уме крупными блрками
На уровне связей блоков вроде все должно быть ок
Начал лепить по принципу сверху вниз
Что получилрсь то и получилось
Приемки и тестов по сути никаких нет
Потому что ни один из формулировавших задачу так и не сформулировал задачу
А сформулировал свое частное видение своего счастья
Котрое никак не клеится со счастьем других
Итого сам типа тестирую
Сам загоняю в продакшен
Кушайте то что есть ибо так понял и так сделал
Не нравится - пишите мессаджи
... Мессаджи приходят обычно только в первые день два если вылезли большие грабли
Грабли которые вылезли потом типа тут у вас неправильно потому что.. Ответ даю обычно такой - это не озвучивалось вами при обсуждениях, так что ешьте что есть сейчас - будет время - может поправлю
как вы будете проверять, что я сделал, то что вы хотели?
Важно формулировать его именно так. Именно с этого вопроса можно выходить на BDD. Не "как это должно работать" и не "что должна делать программа" - это выход на функционал и тупик. Если заказчик не может сформулировать, как он это будет проверять - то вы совершенно спокойно ему говорите: вы сами не знаете, что хотите, откуда же мне знать, что я должен вам сделать? Это страховка от дурацких "pet features" и собственно те самые критерии приёмки. Даже без Геркина это будет полезно. Когда есть пример - и разработанный вами функционал позволяет его реализовать, значит вы сделали то, что хотел заказчик. Если после сдачи работ внезапно заказчик кричит, что ничего не работает - вы спрашиваете: как вы проверяете? И снова от него должен пойти тестовый пример. Если этот тестовый пример не противоречит тому, который вы получили до разработки - значит ваш косяк, и вы чините всё бесплатно. Если противоречит - то вы говорите: позвольте, но...
Для себя мы установили, что тестовый пример должен содержать три раздела:
- входные данные
- описание действий
- выходные данные
С одной стороны такая формулировка не ограничивает формализацией полёт мысли бизнес-аналитика, с другой стороны это даёт чёткий выход на BDD c его Given-When-Then для последующего написания сценария.
Подробнее о работе с требованиями постараюсь написать в следующей статье.
И ещё.
Меняю эту историю на success story. Идёт? ;-)
На самом деле проблем с успехом и историей нет. Постараюсь выделить время и оформить статью.
знаете, уже изрядное количество "бизнес-консультантов" на ИС отговорилось именно такой формулировкой, так что неоргинально отмазываетесь)) Лишь раз потом ссылка и статья воспоследовали...
Скиньте прям сюда, без изысков, какой проект с применением всего изложенного в публикации успешно выполнен, а мы уж сами проанализируем да полюбопытствуем. Вы же согласны, что если проект действительно удачен, то это очевидно невооружённым глазом, и такого мнения придерживаются большинство ключевых фигур?
Наоборот - меня консультировали, я воспользовался, получил некий опыт - и делюсь им. Заметьте, что весь тон статьи выдержан в критическом русле. Я же не доказываю с пеной у рта, что BDD - панацея, зачем же Вы мне (и всему сообществу) доказываете обратное и требуете каких-то доказательств успешности? Я пробую, мне нравится - делюсь опытом. Если кто-то ещё пробовал и хочет обсудить - я только за. Вы же не пробовали?
Эту статью, @Pr-Mex не даст соврать, я готовил довольно долго, потому что к подаче материала отношусь достаточно ответственно. Следующая тоже появится не быстро. То, что следующие статьи будут, я сразу анонсировал. Поставить приоритет на "success story" - Ok. Что ещё надо?
Но какие-бы не были претензии к образованию, но без теории только напильником сможешь доработать, а построить новое нет.
Бух 3.0 мне по юзабилити значительно больше нравиться, чем 2.0.
Разве разработчики типовых работают по новым методам? По новому они не работают, соответственно и нет ожиданий, по ясности и простоты кода в типовых конфигурациях.
Удобство конфигуратора - тут нечего сказать, т.к. лечат они нарывы, а не болезнь в целом, и тут никакие TDD и BDD и отжал не помогут, если на входе не поступает адекватных задач.
По остальному - ну, была ж такая попытка, СППР называлась... Там даже типа ER-диаграммы были)) И где это всё?
Вообще, народ, если кто не был ни разу на Infostart Event, очень советую, после посещения будете хотя бы смотреть в правильную сторону.
Сам пока не решусь начать делать всё "по правильному", поэтому пока посижу послушаю, развесив уши.
Ещё раз спасибо.
Даже если один в поле воин как (15), главное вовремя менять шляпы и по другому задавать самому себе вопросы.
p.s.: заказчиком может ведь быть не только конечный пользователь, но и ваш внутренний перфекционист, говнокодер и т.д.
А уже потом можно разбираться, дает выхлоп вся эта связка или можно выкинуть более трудозатратную ее часть, например БДД.
А до СС это просто предложение убить с месяцок 100% загрузки одного-двух человек разово + замедлить разработку новых фич в 1,5-2 раза на постоянной основе в обмен на обещание снижения затрат на поддержку.
Опять же, раз "Внезапно BDD – это не о программировании, а о бизнес-анализе.", то первый вопрос не столько "Кто из ваших сотрудников будет этим заниматься?" Аналитики будут, это понятно. Если на проекте программист класса "внедренец", то он. Если выделенный аналитик, то он, тут все просто.
Важнее - а как мы продадим эту непонятную древовидную структуру заказчику? Про существование ГОСТ на ТЗ по АС знают все, даже если номер не помнят. А вот сценарии, особенно в режиме "вы нам подпишите интегральный сценарий, но на самом деле там еще внизу куча параметров, но вам их знать не обязательно" надо продавать указывая на успешные истории.
* приемосдаточные испытания - "BDD run"
* валидация требований и системы созданной по ним - "Make AutoInstruction"
Сейчас это все делают вручную, и в основном хитрят и пропускают эти этапы.Напомню что всё что вы указали - как раз и сокращает затраты на эти этапы. Потому что они проходят автоматически. Больше могут вам рассказать ребята из КРОКа, если захотят. Насколько я вижу по активности на github - они после практических апрельских занятий внедрили у себя эту технологию.
Вот, а вы предлагаете не хитрить, и, соответственно стоимость этих этапов увеличить. Плюс еще, чтобы выйти на автоматизацию этих этапов ухнуть кучу ресурсов предварительно.
Если УЖЕ есть БДД и геркин, то при помощи Ванессы можно сократить затраты на эти этапы. А если нету, то переписать ТЗ (а его ведь все равно писать, бумажка с подписью-печатью нужна) в Ванессу это как бы не дороже, чем посадить стажера, чтобы он провел руками один раз все по цепочке делая скриншоты раз в 15 секунд. Вывести это в документ ворд, и дальше приемочные тесты и валидация - головняк и затраты заказчика. (а танцы с Ванессой - наш).
Я понял, что мне напоминает БДД - налоговый учет в чистом виде. Некая альтернативная техническому заданию (БУ ;) система учета (требований к функционалу), которая дает нам упрощение одного из моментов разработки (дает подсчитать налог на прибыль).
Но остальные то моменты сильно проще не становятся. Плюс возникнут ВР и ПР, без них никуда - или что-то реализовано, но нет в фичах (типа обработки замены значения) или описано, но пока там заглушка. И исправлять ее не приоритетно.
В общем, я уже вижу прибыль от хЮнит, но про БДД в условиях плывущих хотелок заказчика в итерационном стиле "ну вы принесите, я посмотрю, скажу что исправить" (причем как интерфейсно, так и алгоритмически) у меня пока сомнения.
Когда затраты на поддержание и внедрение этих технологий будуи меньше получаемых в результате профитов - тогда и взлетит
Мне gerkin - по крайней мере то что я посмотрел в вебинарах и статьях типа этой - вызывает крайне положительные чувства, потому что это не протворечит моему чувству прекрасного, а наоборот очень близко к нему.
Но я сейчас пытаюсь представить какую-нибудь задачу из более менее немелких, которую я мог бы запустить по этой технологии и выпадаю в осадок, просто потому что я понимаю что внедрение такой технологии приведет меня к реорганизации всего процесса общения итгруппы и остальных подразделений причем я предвижу что период согласования будет неимоверно удлинен, а период разработки ничуть не меньше. И при этом еще нужно понять нужно ли заказчику качечтво ДЕЙСТВИТЕЛЬНО? Или ему нужно удовлетворение текущих сиюминутных потребностей? Пока вижу в основном второе, и в первую очередь потому сто куча еонтор работает безо всяких стандартов и регламентов. А работать так как в статье - это надо чтобы понимание о необходимости использования стандартов и внятных технологий было не только у меня но и у моих заказчиков-подразделений
Пипл в том числе и злесь испытывает имхо большой скептицизм
Нужен проект доминикана
Реальная задача которая несделана и которая нужна еомуто
И с нуля до финиша - полный реплртаж из лаборатории
Вживую
Дом2 в миниатюре в варианте ФранчТоп или ФрилансГууд
Короче
Чувствую что реально должно быть здорово, но здорово опасаюсь все это припенять на практике
Проводили цепочку регламентного процесса от заявки покупателя до реализации и отгрузки со склада только в отличие от реальности прогоняли воздух. Примерно пятьшесть ключевых точек - на каждом бздынь лбом об ошибку/блокировку процесса - потому что то это не выполнено, то это не заполнено И так далее
Я как представлю что у этих людей я буду выпытывать и строитьописывать по gerkin - да меня нахрен пошлют - потому что ответ на каждый вопрос пораждает дветри альтернативы и на каждыую либо надо дать ответ либо поставить блокировку - ибо дырки оставлять нельзя - и мне скажут не сношайте мозг сделайте что нам надо вы что тупой ре можете понять...?
Короче и хочется и колется
Самое главное - как только заказчик начнет мне платить за процесс согласования и утрясания - так я с большим удовольствием буду все формализовывать и детализировать и раскладывать в глубину до состовляющих. Ведь качество само по себе не выродится - за него надо заплатить
Да, если вы конторв работающая по проектам на внешних клиентов - да, можно выставлять клиенту все как есть
Возможно я нетрезво оцениваю но - то что сейчас клиент платит стотыщ мне - если я начну работать правильно - это будет стоить по грубым оценкам ну раза в три четыре больше клиенту. Будет ли клиент работать по таким расценкам? Очень сомневаюсь. Хорошо когда клиент такой что на него гадо работать целой команде из пяти человек
Короче опять у меня все мутно и непонятно
Неправильные у меня клиенты
И я мутный
Если возможно - напишите состав команды проекта и кто какие роли выполняет и какие ресурсы тратит при этом?
Вот именно после таких, простихосспади, консультантов и приходится нам, рядовым разрабам, трудиться день и ночь, обеспечивая реальную работу реальной компании, а не коня в вакууме.
Мутные мы, CheBurator, мутные, что поделаешь. Непроцарапанные. И клиенты у нас тёмные, и сами мы быдлокодеры)
p.s. представил, как я где-нибудь на собеседовании, на вопрос об успешных своих работах, ляпнул бы нечто вроде "ну, я об этом не рассказываю, чтобы вызвать чувство зависти итд". Или на корпоративном сайте, где все нормальные компании гордо публикуют свои достижения, красовалось бы подобное. Смешно, не находите? Смешно и глупо.
Денис CTO во франче. Поделился опытом внедрения технологии. Причем достаточно объективно. И про ириски и про риски написал. Задачи впаривать вам технологию нет. В наших прайсах продажи технологии внедрения по BDD не значится. Писать саксесс стори только для того , чтобы потрясти общественность неинтересно. Кроме того саксесс стори для покупателя она не равна саксесс стори для коллеги по цеху. Для покупателя это отчет о качестве в аллюр весь такой зеленый и красивый, это отчет о количестве ошибок в системе и приятной техподдержке.Это скорость внедрения функционала. И т д.
А для коллег по цеху это совсем другая история: это про шаблоны документации по проекту, это про себестоимость проекта,, это про возможность вернуться к проекту без потери контекста и легко вернуть заказчика в конструктив.
А для программистов , которых хочешь привлечь на работу это третья история. Про то как можно формализовать поток хаоса от заказчика, про то как можно ускорить разработку за счет инженерных практик и т д
Так вам какую историю и зачем? Если есть клиенты и - пишите. С удовольствием присоединимся к продаже со своими историями. Естественно за деньги. Если нужно оптимизировать процессы - это вообще не к нам. Это к консультантам. Если хотите работать у нас по технологии и вам интересно впахивать в три раза больше чтобы научиться новым технологиям и получать удовольствие от создания красивых и функциональных продуктов - рады видеть в команде.
Еще раз повторюсь: сей пост не является рекламой тренингов, продуктов, консалтинга и прочих коммерческих ересей.Это приглашение к объективному обсуждению плюсов и минусов. С серебряными пулеметами 1Сервис дружит. Но проценты от их продаж мы не получаем. Да на многие подходы у нас диаметрально противоположные взгляды. В одном мы сходимся точно - в отрасли бардак и с этим что-то надо делать.
Всем удачи и хорошего остатка рабочего дня ;)
Рискуя оффтопить, приведу простой пример. Ницше всего лишь выстроил философскую концепцию. Спорную, сложную, неоднозначную, но могущую иметь прикладную пользу. А потом пришли другие, восхитились, ух типа крутая мысля, попробую внедрить. Что было дальше, читаем историю ХХ века. Аналогичная фигня произошла с десятками других научно-философских, когнитивных, социо-психологических и прочих наборов инструментариев. И ни разу - повторюсь, НИ РАЗУ, это не было воплощено так, как описано. И по пальцам пересчитать, когда хотя бы с натяжкой можно счесть результат положительным.
Автор темы предлагает нам светлое будущее и методы его построения. А я вижу, что практика применения этих методов выглядит как мрачное вчера и безысходное сегодня. С августа 2015 и по сей момент вижу, аккурат последствия следования таким методикам. А учитывая, что сторонники "светлых идей" не приводят ни одной "истории успеха" (спасибо хоть не стремятся причинять добро и горды этим), всё это для подавляющего большинства сообщества должно восприниматься как минимум ооочень скептично.
Читайте прямо, а не по диагонали, автор ничего никому не предлагает, а лишь делится своим опытом и наблюдениями.
TDD известен с начала 2000-х
Первый фреймворк для работы с BDD (Jbehave) вышел почти 10 лет назад
По-моему давно пора признать что QA в 1С нужен также как и в других областях IT. "Бах бах и в продакшен" - устраивает далеко не всех.
Значимы только опыт применения, желательно успешный, и люди, готовые сами пройти путь от "ясделия" до нормального проекта и продукта. А я за 15 лет наблюдений на эту тему видел только сперва умные рассуждения, а потом в кусты и досвидания. Практика - критерий истины. Нет практики - сами понимаете.
По поводу автогенерации юмл - знаю, генерят и код по схемам и наоборот, но для меня главная ценность в наглядности схем - сдобренная обстоятельным попунктным описанием очень хороша в техпроекте или тз.
А если вспомнить о необходимости тестирования, то мне нравятся сценарии/протоколы тестирования, и я не об автотестах, а о ту-ду и чек-листах.
Т.е. после выполнения какой-то задачи вы прогоняете руками весь чек лист.
Потом появляется новая задача и новый чек лист. После окончания выполнения второй задачи вы прогоняете первый и второй чек лист. Так?
И сколько чек листов у вас сейчас для вашей любой конфигурации?
Скорее всего просто прогоняется одна маленькая выполненная задача вручную единожды при сдаче и забывается. В конфигурациях же нет никаких взаимосвязей между объектами и модулями ;)
И еще - вот в этой статье бдд практически и сведено к совокупности ту-ду и чек-листов, только в форме, которая жрет мой когнитивный ресурс, который я бы предпочел тратить по прямому назначению.
Я их на предметном уровне как тупой юзер тыкать буду, есть мнение что будут ломаться Мной на раз
??
У вас на проектах разработки есть люди-тестеры?
- стандартизация
- автоматизация проверок/тестирования
Это ведет к основному нужному для ИТкоманды результату: устойчивости системы после внесения очередных измененений. Что надо итшнику? Когда в отпуске в доминикане - чтобы не дергали аааа все сломалось аааа...
Поэтому основная фраза когда я в очередной раз линяю: "1. Новых схем не изобретать 2. все что можно отложить до моего возвращения - откладывать".
;-)
И совершенно четко видно - все меньше и меньше на рынке продаж результата, а все больше и больше продаж процесса достижения результата
А вот будут ли все покупать лексусы, или большинство будет ездить на логанах - это вопрос ценовой ниши, качества, и удобства
В известных мне компаниях - бардак бардаком, только некоторые при этом ещё делают вид, что работают с соблюдением умных теорий.
На нашем рынке услуг выигрывает не тот, кто делает качественно, а тот, у кого круче связи и блат, больше понтовых бумажек-лицензий-сертификатов, наглее лобби в тендерах, ярче реклама и нахальнее продажники.
Народ, ну вы как с Луны свалились, право слово.
И да, мне как-то поднадоело, что в компанию приходят шибко продвинутые РП, знающие всякие умные проектные технологии, а потом начинаются проблемы на уровне банальных ТЗ и техпроекта, и эти РП сливаются, а "простым парням" в итоге не хватает на лапшу, не то что на всякие доминиканы.
При этом, каждый новый "умник", конечно, поливает последними словами предшественника, ибо носитель истины известно кто.
p.s.: имхо, комменты можно прекрывать, т.к. скатились во флуд.
Троллинг насчёт асоциальности элегантен, но мимо, мимо, ибо слишком толсто)
Прикрывать ли тему - решать модераторам) Хотя я полагаю это не флудом, а концептуальной нестыковкой участников.
я, собственно, почему против фичи в сабже:
разделение Т предполагает обмен
что получают рабы от аббревиатурных юзеров - не ракрыто
То что это не было сформулировано до Адама Смита ещё не означает что этого не было раньше.
эээ не надо смс-колбасинг рассматирвать как тестинг петтинга!
тут все зависит от личного позиционирования.
когда я в проекте как простой исполнитель - но на меня начинаю неявно спихивать организхационно-управленческие проблемы по проекту - я успешно вежливо посылаю наюг (ввиду личных обстоятельств я могу себе это позволить и нифига не боюсь) и говорю прямым текстом - вы хотите чтобы я решал ПРОБЛЕМЫ - не вопрос - давайте обсудим цену. на этом все кончается. так вот один проект уже года два... тянется...
или я беру участок на себя и сам выступаю как РП. успешно или нет - хз, но претензий никто не выкатывает в итоге. деньги платят, хватает и на лапшу и на икру...
так что - РП тоже непросто - у них свой уровень проблем - главное чтобы каждый занималсмя своим делом...
Мне кажется что успех больше зависит от того какие ценности/идеи исповедуют члены команды
Могут быть и сильные специалисты а успех не очень
В сложных проектах имхо большую роль играет координация и управление и здесь тоже в е непросто
- неа, это неправильный подход. то что можно сделать и запилить автоматически - должно быть сделано автоматически. Потому как какие бы ты регламенты-инструкции-меры при РУЧНОЙ работе в условиях кучи альтернатив не принимал - НАКОСЯЧАТ!
другое дело, что я категорически против когда организационно-управленческие проблемы пытаются начинать решать на уровне технологий/автоматизации. не, я такие проблемы тоже решаю - но выкатываю большой ценник.
человек, у которого есть деньги, чтобы купить что-то автоматизированное
и человек, который за эти деньги может что-то автоматизировать
если слишком сложно, то декомпозиция (одного умного слова достаточно)
кто-то может ее решить, кто-то нет
2. для решения проблемы могут быть какие-то инструменты (проджект-манагер, например)
кто-то умеет юзать п-м, кто-то нет
пп 1. и 2. вовсе не связаны между собой прямо
чаще всего их связывают простым надуванием щек
Угадайте в каком ресторане BDD.
p.s: во втором примере у вас какой-то фастфуд описан, за 2 минутки, быстро, сытно, вкусно и вообще рестораны не нужны.
Зачем он вообще в ресторан пошел? Мог купить типовой полуфабрикат и не напрягаться вообще. В 10 раз дешевле и быстрее.
Либо ему приносят стейк из цветной капусты и говорят, что предыдущему посетителю такой стейк очень понравился, значит и вам понравится. И далее по сценарию (110)
Встречаются два музыканта:
- Привет, я вчера купил твой новый альбом!
- А, так это был ты...
я не знаю ни одного рецепта, который позволяет безошибочно и гарантированно вместо 10 по 100, набрать 5 по 150
5 по 150 набрать не так уж и просто. Их просто нет в свободном доступе
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 534673
Создание 03.07.16 21:26
Обновление 03.07.16 21:26
Просмотры 32095
Загрузки 0
Рейтинг
138
Комментарии 131
Код открыт Не указано
Рубрики Тестирование QA
Кому Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация Универсальные
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
