Достаточно часто на ресурсе выходят статьи представителей франчайзи. Иногда - интересные и нужные. Иногда - не очень интересные. А еще регулярно статьи, чтение которых способно ввести в депрессию.
И то - скромные авторы пишут о стандартах разработки, о том, как надо писать код, о том, как надо внедрять, как работать с заказчиками, как персонал мотивировать, как проекты вести и “как сделать за пять минут то, на что у других уйдет год труда”. Статьи обильно приправляются сентециями типа “В нашей компании мы всегда работаем по самым высоким стандартам и тому-же молодых сотрудников учим”, “у нас есть в компании правила разработки, правила групповой работы, а еще мы внедрили скрам и стали на 99% процентов эффективнее”. Читаешь и чувствуешь, что сам-то ты отстал от сверх-высоких стандартов, что надо догонять, что все вокруг программируют на недостижимом уровне, и ты - никому не нужный мастодонт, реликт и музейный экспонат.
Для тех из коллег, у кого подобные мысли возникают, я и решил тоже несколько живых кейсов привести. Только не из неких заоблачных стандартов - а из самых что ни на есть актуальных продуктов. Продуктов, которые отдельные “партнеры” вполне себе продают клиентам. Ну и раз уж я Agile упомянул - скажу пару слов и о живых примерах групповой работы во франчайзи - из того, что лично видел.
Итак - как накодить за 20 секунд то, на что другие целый день убьют? Нужно придерживаться золотого правила минимализма. Например - зачем вот нужны регистры сведений? Дураку понятно, что это все от лукавого. Вместо регистров сведений вполне можно обойтись реквизитами справочников! И вот живой пример - продукт от “партнера 1С”, который вполне себе клиентам продается.
Справочник “Номенклатура” - смотрим и ценим (часть реквизитов я стер на скриншоте, чтоб решение не сразу угадали). Люди вводят реквизит - цена1, и не нужно никаких там разных регистров сведений и документов установки цен тем более. Просто, быстро, красиво. Правда вдруг может понадобиться еще один вид цен - ну не беда, добавим еще один реквизит. И еще один. На моем скрине 12 видов цен - 12 реквизитов. Ну и цена закупки отдельно. Пока, видимо, не нужно было больше.
Точно так же можно (и нужно) упрощать все остальное. Вот, например, - нужно добавить информации в справочник. Фирма 1С придумывает для этого не-пойми чего. Какие-то регистры сведений, планы видов характеристик, табличные части с доп реквизитами. А потом, чтоб эту информацию извлечь, хитрые запросы к данным строят. Для “эффективного” кодера все это лишне. Добавил два-три реквизита прямо в справочник или документ - и проблема решена. А как же быть, если заранее неизвестно, какая информация нужна будет? А очень просто - заранее добавить реквизитов и назвать их просто и красиво.
Как на скриншоте - “Свойство1”, “Свойство2”. Просто и красиво, прямо как в 1С 7.7 было. Этот продукт люди пользователям продают. И разумеется - с контрагентами все точно так же. “Категория1”, “Категория2”.
Все прочее - тоже реквизитами. ABC категория, должностное лицо-руководитель, должностное лицо - главный бухгалтер - все строго реквизитами. Зачем придумали регистры сведений? Не нужно это, и без того продукт можно “впарить” клиенту. И доработать быстро - нанял студента за пачку пельменей, он и добавит еще реквизит (или два реквизита, или сто - все одно не дороже пачки пельменей выйдет).
Что на сайте самой компании, которая такие чудо-продукты производит, сказано? “один из крупнейших российских системных интеграторов и независимых разработчиков типовых программных решений на базе "1С" для автоматизации… Основная сфера деятельности группы компаний полный комплекс услуг по автоматизации бухгалтерского и управленческого учета предприятий и организаций любых отраслей бизнеса, от индивидуальных предпринимателей до холдингов. Группа компаний ...основана в 1993 году. С 1997 года ... является партнером фирмы "1С". За время сотрудничества накоплен обширный опыт внедрений в различных сферах бизнеса и в области государственного управления. Это подтверждают сертификаты и статусы, полученные ... а также статистика работы”.
Является партнером 1С с 1997 года.
Является партнером 1С с 1997 года!
Является партнером 1С с 1997 года!!
Но - я отвлекся. Я обещал показать, как можно программировать легко и просто, а сам на первом же кейсе завис (в офигении). Так вот, урок второй - регистры накоплений на самом деле тоже совершенно не нужны. И то, каждому разумному человеку ясно, что все нужные цифры уже есть в документах, для чего повторно информацию в регистры пихать? Не нужно этого делать! И вот вам еще один живой пример.
Тут мы видим, как легко и просто можно обойтись без всяких дурацких регистров. Нужно узнать, сколько нам клиент оплатил? Считаем строки документа прихода денег, и сумму узнаем. Просто? Просто! Быстро? Быстро! Смешно? А коллега мой за голову держался, у него из-за такого чудо-кода клиенту без оплаты отгрузили чрезвычайно дорогостоящий товар (потому что помимо приходников там у клиента в истории и расходник фигурировал, и сумма оплаты из-за этого получалась сильно ниже).
Этот программный продукт продают клиентам!
Этот программный продукт продают клиентам за деньги!!
Этот программный продукт продают клиентам за деньги прямо сейчас и в нашей стране!!!
И раз уж начали - по методологии работы. Отдельные шибко умные люди непонятно зачем любят умножать сущности. Вот например - партионный учет. Зачем-то документы партий в регистрах используют, аналитики всякие, разные ФИФО и по-средней, давят умняка, короче. Тру-специалисты не заморачиваются такой фигней, и поэтому их партионный учет прост и создается за пять минут.
И снова живой пример. Делаем справочник партий.
Партию указываем прямо в документе прихода - причем человек может партию выбирать или же программа автоматом создаст.
ФИФО и всякое скользящее - это от лукавого. Ставим просто - списывать самую старую.
Регистр партий делаем простой - номенклатура, склад, партия как элемент справочника. И при таком грамотном проектировании наши запросы будут невелики и создавать их можно будет секунд за 30. Примерно так это будет выглядеть - код на списание по регистру партий.
Как видим - все очень просто, никаких километров кода, как разные несознательные личности делают - не нужно. Все предприятие с таким подходом легко за пару рабочих дней автоматизировать, причем код с нуля написав и под требования заказчика. Понятно, что потом клиенты будут плакать, и за голову хвататься - ну да вы в этот светлый момент уже будете автоматизировать кого-то другого.
Ну и раз уж мы заговорили о франчайзи - нельзя несколько слов не сказать и о методах работы отдельных из них. Как говорится - не скрамом единым.
Помнится, в свое время меня потряс список требований одного франчайзи к удаленным разработчикам. Документ был большой, детальный, расписывалось, куда и как ставить точки, какие отступы в коде делать, требования к комментариям. Отдельно и очень много - что надо делать все, что в техзадании расписано. А если в техзадании вдруг что-то не указано - то надо догадаться, что это подразумевается, и тоже сделать. И на сладкое - приводили пример реального диалога с разработчиком, которого совестили и стыдили. Я начал этот диалог читать, и понять ничего не могу. Вернулся к началу - ну да. “Читайте этот диалог снизу вверх”.
Читайте этот диалог снизу вверх!
Читайте этот диалог снизу вверх!!!
Может это и был самый мудрый в мире франчайзи - но меня охватило глубочайшее отвращение. Писать километры требований к чужому коду - и не взять за труд себе даже эти требования хотя бы читаемо оформить.
Еще, помнится, очень понравился ролик одного франчайзи, чье название что называется - “на слуху”. Лукавый человек с хитрым взглядом в ролике долго рассказывает, какая у них замечательная фирма. И какие стандарты высокие - и в разработке, и во взаимодействии. И что они бы могли еще сильнее развиться, но не хватает разработчиков. И в конце просто шедевральную фразу выдает: “У нас нужно в проекты вписываться. У нас вот недавно устроился разработчик, он сидел, ждал пока ему работу дадут - ну и уволился через месяц, не дождался”. Человек на голубом глазу подает, что вот, какой не шустрый разработчик оказался, не стал сам бегать и искать, чё кого. Про то, что у человека по идее должен был менеджер быть, который хотя бы какие-то правила игры мог бы и объяснить (ну или HR на худой конец, который должен был провести мероприятия адаптации) - про это ни пол-слова. То есть у вас в компании такая “замечательная” культура, что новым людям не оказывается никакой поддержки - это ладно. Но зачем тогда говорить, что вам разработчиков не хватает? Может быть, с себя стоит начать, подумать, отчего люди приходят, сидят в недоумении и уходят? Ну это ведь не так интересно, как рассказывать басни про скрам и выигранные тендеры.
Чтоб не голословно было - вот несколько цитат с сайта компании (про скрам и agile - тоже есть). “в приоритете индивидуальный подход к каждому сотруднику”, “Этому же учим сотрудников, повышая их мотивацию на собраниях и тренингах, есть коуч-тренером в отделе, мы изучили множество тематических вебинаров по программам 1С, и адаптировали их под специфику работы своего отдела.. совместное обсуждение в коллективе позволяет сотрудникам глубже изучить материал, досконально освоить используемое в работе программное обеспечение. ”, “руководитель отдела всегда готова ответить и помочь коллегам, у которых в работе случается всякое: опускаются руки, снижается мотивация, энтузиазм. Тогда ищет нужные слова и стимулы, которые помогут раскрыть потенциал человека, вдохновить, подбодрить, показать перспективу. С каждым детально разбирает ситуации, которые привели к сложностям, ищут варианты решений”
Месяц человек просидел за столом и уволился!
Месяц человек просидел за столом, никто к нему не подошел и он уволился!!
Месяц человек просидел за столом, ему не дали работы и его зарплата по итогам месяца была никакой и он уволился!!!
Индивидуальный подход к каждому сотруднику!!!!!
“Тема обсуждения: почему IT отдает предпочтение именно Scrum” (с)
“Если есть необходимость быстро получить рабочее ПО то смело выбирайте технологию Agile” (с)
.
Еще случай из практики франчайзинга (другая фирма). Менеджер берет заказы у клиентов в обход руководства. И программистам также в обход руководства кидает. В итоге несколько команд в одном коллективе - одни вроде б и заняты, но заказы у них “тощие”, и работа ведется кое-как. А другие вроде б и не заняты почти, и выработка минимальна - но жирные заказы уходят к ним слева, и времени у них по факту нет - а уж на групповые стандарты и командные методы им просто фиолетово - люди по факту в другом месте работают. В итоге может быть несколько десятков разработчиков - а поставить на проект и некого.
И нельзя ни сказать о замечательной и чудесной практике под названием “Кому отдать проект? Тому, кто поставит меньше часов”. Как это выглядит? Примерно так же, как написано. Поступило ТЗ от заказчика. Большое такое, основательное ТЗ. Страниц на 50, к примеру. Кому отдать такой заказ, если у вас под началом 50 голов разработчиков? Разумеется, тому, кто меньше денег попросит - то есть тому, кто выставит за работу как можно меньше часов. Выглядит это примерно так. На корпоративном портале появляется новость - “Есть ТЗ, кто возьмется?”. Разработчик Вася со стажем в 15 лет разработки в серьезных проектах только заканчивает читать 30-ю страницу ТЗ, думая при этом, что 90% описанного уже есть в продукте “1С-Совместимо”, с которым он раньше работал, а вот оставшиеся 10% - с ними нужно месяц возится, потому что сложно. А студент Петя, который вчера сдал на “Профа” по платформе, уже пишет - “Возьмусь за проект, 80 часов”. Как мы видели по приведенным выше примерам архитектуры - любое задание действительно можно сделать за 80 часов - отказ от регистров, от методологии, и на выходе получается проект из разряда - “Наверное, это все же лучше, чем в экселе посчитать.. или не лучше?”. В итоге проект уходит студенту Пете. Ну а опытный разработчик Вася, несколько подивившись такому пиру жизни, через какое-то время уходит на фикси, куда его давно звали.
И чтобы уж совсем закрыть тему, еще два слова о наболевшем. Пришлось не обновленную адаптировать УТ 11.3 к переходу на 20% НДС. Мне казалось, что задача не будет сложной. Добавить новое значение в перечисление “Ставки НДС”, потом проверить, и всех дел. Я оказался сильно не прав. Отчего-то в типовом решении 1С этого было недостаточно. Потому что были буквально сотни строк кода, типа
И для новой ставки НДС нужно было добавить еще кода. Сотни таких мест, увы. Что мешало вообще сделать “Ставки НДС” не перечислением, а справочником, что мешало сделать одну обработку значения ставок в функции и вызывать эту функцию везде? Вы знаете ответ на этот вопрос. Так что - когда вы читаете очередной рассказ о скраме, Agile и прочих зарубежных словах, не спешите впадать в депрессию и считать себя безнадежно отставшим. Вполне возможно, что у рассказчика дела с высокими стандартами обстоят еще хуже, чем у вас, увы.
Alexander Chernykh
