Внутренняя организация франчайзи

1. 25.02.21 05:50 Сейчас в теме
Хотел написать комментарий к одной новости на инфостарте, когда начал проходить тест: https://infostart.ru/journal/news/mir-1s/otseni-svoi-znaniya-po-sostavleniyu-tz-i-poluchi-metodicheskie-materialy_1391331/ , но в итоге решил отдельную ветку создать.

Чистосердечное признание: когда я в статье (в данном случае в тесте) вижу такие слова как product owner, бэклог, технический проект, бизнес процесс, agile - чувствую себя колхозником. Я конечно понимаю смысл этих слов, мне нравятся новые слова, легко найти их смысл в интернете, но в нашей франчайзи такое не используют вообще. У нас нет руководителей проектов, продакт менеджеров, технических директоров, аналитиков. У нас есть: менеджеры (они главные), консультанты и программисты (обычно подчиняются менеджерам). В основном вся наша работа между менеджером и программистом построена на следующих фразах взаимодействия: "сколько нужно часов?", "загугли", "позвони в техподдержку", "напиши на v8", "напиши на lic", "поговори с клиентом", "возьми задачу", "когда закончишь?", "ты не знаешь как делать?", "всё сделаем", "сдай задачу", "выстави счёт" и "клиент жалуется".

В связи с этим у меня вопрос. Вы действительно используете в своей организации эти слова и эти методики? =) И как? Повышает эффективность?
ubnkfl; pyrkin_vanya; _MavR_; Nubsdale; +4 Ответить
Ответы
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
8. _MavR_ 25.02.21 15:39 Сейчас в теме
(1)
Повышает эффективность?
+5 к солидности и +3 к ЧСВ оно прибавляет. У селедки тоже много названий, но внутрення суть от этого не меняется.
9. van_za 125 25.02.21 17:21 Сейчас в теме
(1)
почитал и сразу понял что не смысла проходить тест :)
16. eselyanina 26.02.21 11:38 Сейчас в теме
(9)
Мы организовали этот тест для того, чтобы докладчики разговаривали с участниками митапа на "одном языке" и могли адаптировать свои доклады под аудиторию. Конечно, для многих практиков нет смысла проходить этот тест. Тем не менее, этот опрос прошли 196 респондентов, не много, но тем не менее. Значит кого-то опрос заинтересовал.
Teut_Vlad; +1 Ответить
19. win.s.1 01.03.21 11:18 Сейчас в теме
(16) интересное мнение. "Докладчики разговаривали с участниками на одном языке."
Я так понимаю докладчикам проще переучить всех, чтобы они понимали/использовали термины к которым привык докладчик ?
Или все таки - лучше использовать ту терминологию которая принята в текущей среде ?

Вам не качественно поставили ТЗ на подготовку теста.
1. 1с это предметно ориентированный язык программирования.
На него не всегда можно транслировать практики (кейсы) - которые применимы к традиционным языкам программирования.
2. Нужно оценить знания по постановке тз (т.е. качества технического задания) или оценить свои знания по управлению жизненным циклом технического задания? Судя по вопросам - смешалось все.
27. UtSpar 06.04.21 15:56 Сейчас в теме
(1)
Повышает заменимость сотрудников, правила работы в зависимости от роли определяются легко.


ну и как минимум экспериментальное применение некоторых методик позволяет позаимствовать лучшее, подходящее. у вас же тоже не с первого дня был менеджер, консультант и программист.
2. muskul 25.02.21 06:55 Сейчас в теме
бизнес процесс - ты не знаешь как делать?
технический проект - возьми задачу
agile - сколько нужно часов, когда закончишь

Как по мне 95% так и работают. я в том числе.
UtSpar; Aleksey_Abramov; Nubsdale; +3 Ответить
3. glek 112 25.02.21 07:15 Сейчас в теме
У нас, в бытность работы на франче, были консультанты (которые работают по "рознице"), аналитики (которые работают по проектному направлению), РП (аналогично), архитекторы (которые работают по проектному направлению и отвечают за качество разработки. Никаких добавлений метаданных или чего такого без согласования с архитектором не допускались) и разрабы.
katenok86; +1 Ответить
4. user1488313 25.02.21 08:42 Сейчас в теме
У каждой франчайзи свой словарный набор. И если данный "словарь" приелся, то так и живут.
28. UtSpar 06.04.21 15:58 Сейчас в теме
(4) и сколько пройдет времени пока новый сотрудник привыкнет к местным правилам?)
5. user1488313 25.02.21 08:51 Сейчас в теме
А возможно, сотрудники - недавние выпускники IT - сферы. А там данные фразы - это норма.

Как известно - перелезть с одного словаря на другой - довольно проблемно.
6. Nubsdale 25.02.21 09:20 Сейчас в теме
методики, возможно и работающие, но вряд ли кто использует) согласен с автором
7. МихаилМ 25.02.21 13:47 Сейчас в теме
в производстве по еще участвуют тестировщики, дизайнеры юи, технические писатели.
но беда индустрии 1с - феодальное мышление. как нуралиева так хозяев франчайзи. поэтому нет понимания разделения труда. применения различных методик. в сущности программы 1с - это прототипы , а не программы . со всеми вытекающими последствиями в виде упрощения всего : вечно забагованной платформы и типовых конф, далеких от программирования владельцев франчайзи, огромного количества случайных люей среди программистов 1с (учителя инженеры,психологи,зоотехники,военные и т.д.)

поэтому отставание от практик разработки по в индустрии 1с лет на 15-20 будет еще очень долго.
MariaTemchina; +1 Ответить
10. rovenko.n 25.02.21 17:46 Сейчас в теме
(7)
программы . со

Хотелось бы ответить следующим комментарием: пока какая-то другая платформа не сделает нормальную учетную систему для бухучета и прочего опер. контура, говорить, что 1С забагованная - это некорректно. Попробуйте, сделайте. А я сбоку посмотрю с поп-корном.
Aleksey_Abramov; nomad_irk; maXon777; +3 Ответить
20. win.s.1 01.03.21 11:32 Сейчас в теме
(7) Беда в том, что для предметно ориентированного языка некоторые должности избыточны. Например дизайнер.
На задачах от 100 часов, большинство используют и тестировщиков и технических писателей.

Только почему то все обычно сравнивают рынок сопровождения с корпоративным рынком.
Подскажите, а вы видел в западных компаниях которые занимаются чисто суппортом (задачи до 20 часов) - явно выделенных тестировщиков и технических писателей ? Знаю минимум 20 компаний (пересекались по интеграциям) - ни у одной в отделах сопровождения нету этих должностей.

По поводу ошибок - не ошибается тот кто ничего не делает.

Приведу пример ошибки: 10% НДС с 209,39 - 20,94 или 20,93 ? Какой ответ правильный ? Некоторые главбухи считают что 20,93 правильный ответ и 1С косячит.
Это простой пример, который показывает что под ошибкой часто понимают разную трактовку требований законодательства.
(правила округления прописаны в нормативных документах, для того чтобы налоговая не могла за 1 копейку выписывать штрафы)

Или пресловутое "у нас инструкцию читают тогда, когда все уже сломалось"
На гитхабе была интересная статься которую человек написал в стиле "1С глюкавое"
По прочтению - стало понятно, что человек даже не удосужился инструкцию по диагонале просмотреть.
Там во втором шаге уже ошибка, которая привод к такому результату. Но и на это у него был коронный ответ.
"Сделано юзабилити (не интуитивно понятно)" :)
11. rovenko.n 25.02.21 17:52 Сейчас в теме
Скажем так: если люди не кичатся знанием терминов, а реально выполняют работу - да флаг им в руки.
Я просто стыкнулся с тем, что при внедрении подсистемы закупок человек смотрел на меня как на говно, потому что понятие РО - purchase order, он же заказ поставщику, было мне неведомо.
Teut_Vlad; nomad_irk; Batman; +3 Ответить
29. UtSpar 119 09.04.21 12:19 Сейчас в теме
(11) Он его так и называл на английском? Вы не спрашивали а в чем смысл называть русские слова на английском?)
Значимость повысить? не ну это уже террабл))
rovenko.n; +1 Ответить
31. rovenko.n 09.04.21 15:39 Сейчас в теме
(29)это общепринятый термин в SAP ERP, Microsoft NAVision, и еще нескольких больших международных ЕРП-системах. Как ПТУ в 1С. Поэтому человек, считает, что я плохой специалист, раз не работал с системой. Хотя 3 документам можно и мартышку за месяц выучить.
32. UtSpar 119 09.04.21 15:53 Сейчас в теме
(31)
Ааа не знал. Ну теперь плюс один человек кто знает)
12. Vladimir45 75 26.02.21 08:02 Сейчас в теме
Капец....накипело тоже....

"Нужны ли сценарии тестирования в ТЗ?" правильный ответ "Обязательно"
Нет, это самая распространённая ошибка, пихать в ТЗ сценарий? Как вы его туда запихаете, если у вас нет ещё на уровне ТЗ ни архитектуры, ни функциональной спецификации, ни-че-го НЕТ. А сценарий уже есть?

Сценарии тестирования пишутся по FS DS - когда команда создаст проект, опишет его, предложит решения - тогда и пишется сценарий.


"Кто должен писать ТЗ?" правильный ответ "совместная работа аналитика и технического специалиста"
Нет, ТЗ должен писать заказчик (да аналитик и техспец могут помочь) но это документ только заказчика.
А вот когда вы начнете на тз отвечать архитектурой, техническими решениями, тогда это делает аналитик и техспец.
FS DS пишут как раз они.


"Что чаще всего забывают указать в ТЗ? " правильный ответ "права доступа"
Сума сошли? Какие права доступа если нет ещё ни архитектуры, ни технического решения?
Роли должны быть в ТЗ. Описаны что вы ждете от роли пользователя "оператор ТСД", что от роли пользователя "Оператор станка" и т.д.
Какие права? Как в ТЗ вдруг оказалось сразу техническое решение?


Ну как так обучают?
RealSurfer; ice-net; +2 Ответить
17. tindir 26.02.21 14:16 Сейчас в теме
(12) А вот тут есть проблема, когда "мальчик со сцены" говорит, что в ТЗ...нет не так... в ТЗ должен быть сценарий тестирования и описание прав доступа, эти же "мальчики" забывают, что они вещаю для специалистов- и что программист-1с за редким случаем видел ТЗ, в лучшем случае это "пожелание на доработку". Один боец в желтом свитере способен заменить всех этих "ваших" PM PO TM GM и проих обаббривеатуренных. Когда "девочка" с горящими глазами рассказывает про "бережливую разработку" и то что в моменте поступления задачи/таски к программисту ему уже нет нужды общаться с заказчиком, она смело забывает, что у тех кого проавтоматизировало адинэсом, нет денег на "аутсорс девелопмента", максимум на поддержку и итс техно.

Или я, как и автор тоже "колхозник", который не видел больших проектов? Неужели тут все сидят и аутсося Гаспромы-Норникеля-Сбанки?
FatPanzer; +1 Ответить
21. MariaTemchina 1280 02.03.21 17:31 Сейчас в теме
(12) Владимир, с одной стороны я с вами полностью согласна, что вопросы от докладчиков довольно категоричны. Вообще, во всем что касается ИТ-сферы редко можно заявлять "всегда надо делать вот так", чаще всего лучше говорить "я рекомендую делать вот так".

С другой стороны, здесь же не обсуждается "с чего начинается ТЗ". В конце концов, банальности включать в тест и в доклады неинтересно. Здесь обсуждается "от чего ТЗ выиграет/что в ТЗ забывают". И пункты "сценарий тестирования/права доступа" здесь актуальны - возможно, не в начале пути, а когда уже понятно техническое решение.

И вопрос про то кто пишет ТЗ - тоже вопрос спорный. Смотря что понимать под ТЗ. Если и формулировку требований, и техническое решение - тогда ответ "совместная работа" будет вполне правильным. А если требования пишутся отдельно, а техническое решение составляется отдельно - выше риски, что в результате заказчик получит не то, что хотелось бы.
23. Vladimir45 75 03.03.21 18:38 Сейчас в теме
(21)Мария, я готов с вами подискутировать по этому поводу.
Давайте честно признаемся, когда мы пишем ТЗ за заказчика или же помогаем ему, мы навязываем своё виденье. Сразу предлагаем своё решение.
Тоесть мы заведомо пишем ТЗ так, как нам будет удобнее его выполнить.
И избегаем в ТЗ задач, которые мы не сможем выполнить.

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

Пример, заказчик имеет 1000 старых телефонов на palm os. Вот просит он чтоб 1с 8.3 работала в режиме мобильного клиента на старых Palm OS.

Случай раз: Вы с ним обсуждаете ТЗ и уже сразу скажите, мы не сможем там запустить. Даже в ТЗ нет смысла это писать. И не напишете. А потом будет негатив, вот у нас были такие замечательные Палмы, а вы тут их не учли.


Случай два: Если вы получите ТЗ с таким пунктом и ответите ему: никак- выполнить этот пункт не можем. Пальма устарела и её только на уголь.
Никогда негатива не будет. Вот их хочу - вот наше не могу или не реально.
Да мало того, сегодня это не реально, а завтра найдется человек который скажет, а давайте закажем ПО там-то и соединим с 1С. А в первом случае это умрет ещё на этапе ТЗ.
24. Vladimir45 75 03.03.21 19:01 Сейчас в теме
(23)Давайте опишу более приземлённую ситуацию.

У меня идет как раз поиск решения по ТОиР.
Заказчик написал, в карточке оборудования я хочу вести учет комплектности поставки. Сколько там датчиков, какое ПО, какие шланги были внутри объекта и их серийные номера.

Я изучил конфигурацию, написал разработчикам ТОиР - нет такого.
Я отвечаю:
1) разработка - столько-то, будет выглядит примерно так.... скрин с дорисованной закладкой

2) Вводим подчиненные объекты - это будет работать примерно так... и ссылка на видео от разработчика ТОиР как вести иерархию объектов.

3) Храним комплектность штатным механизмом в прикрепленном файле - ссылка на документацию и скрин.

На что заказчик отвечает - 3 вариант огонь. И принимает мое решение на свой пункт ТЗ.

А теперь перенесемся на полгода назад...

А если бы я с ними изначально писал ТЗ, зная что такого функционала нет, я сразу бы написал, будем разрабатывать, раз это очень надо.
25. MariaTemchina 1280 05.03.21 13:00 Сейчас в теме
(24) Владимир, хороший пример приводите.

Только я здесь не вижу противоречия между нашими точками зрения.
Ключевой момент следующий: когда мы обсуждаем с заказчиком, что ему требуется, мы обязательно задаем вопрос "зачем?". И если получаем ответ: "Нам нужен микроскоп для того, чтобы забивать гвозди", то можем предложить варианты, а как еще можно забивать гвозди, и без микроскопа...
Вот в приведенных примерах - про Palm, то же самое - есть задача, чтобы они работали. 1С 8.3. нельзя поставить, но, возможно есть какое-то ПО...
Нужно вести учет комплектности поставки - окей, у нас есть такие механизмы это сделать... (см. ваши варианты 1,2 и 3). Не вижу противоречия, правда!
13. v3rter 26.02.21 08:10 Сейчас в теме
Большинству франчайзи будет достаточно выучить одного переводчика с агильского
14. niko11s 696 26.02.21 10:31 Сейчас в теме
Честно говоря, вообще не понятно на кого ориентируется инфостарт, когда искусственно помещает что-либо в ветку "в тренде", явно не на большинство своих пользователей.
15. niko11s 696 26.02.21 10:34 Сейчас в теме
Создали бы отдельную ветку для этого добра, а то в прошлом году было время, когда там 4 позиции из 5 были их новости про конференции и прочее.
18. win.s.1 01.03.21 11:11 Сейчас в теме
По сути - 80% 1С в большей степени это незначительная доработка уже существующей системы.
Как следствие - все термины приведенные автором в статье - как минимум избыточны.

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

Если говорить за само техническое задание (по всем канонам), то оно регулируется ГОСТом.
Почитайте - там нету терминов используемых в тесте.

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

Если в целом говорить по качеству технического задания:
Уровень детализации и качества технического задания зависит от объемов работы.
Термины - product owner и прочие (спонсор, заказчик) - нужны для проектов от 100 пользователей.
Но тут есть проблема, потому что если мы говорим за большой проект то заказчиков может быть много. В силу специфики.
И все их требования - нужно совместить/разрулить.
У аутсорсеров - все проще. Там действительно можно выделить того одного товарища, которому это нужно.

Самое интересное - качество требований не зависит от знания или использования терминов которые используются в тесте.
Оно зависите от качественных характеристик требований к программному продукту (описаны у Вигерса очень хорошо).
минимум 80% проблем требований связаны с этим. Мелочи которые рушат все бюджеты.

Теперь по тесту: оцени свои знания по составлению ТЗ.
Оценить по сравнению с чем ? Со стандартом ГОСТ? С западными стандартами ?
Или со стандартами придуманными в одной компании, для продвижения своего продукта ?
FatPanzer; +1 Ответить
22. MariaTemchina 1280 02.03.21 17:33 Сейчас в теме
(18) Что для небольших задач глобальные рассуждения избыточны - не могу не согласиться.

А оценить свои знания предлагают докладчики по сравнению с их опытом в данной сфере. Это всего лишь точка зрения, а не догма. Универсальных догм у нас вообще не много.
26. Lukich66 82 20.03.21 10:05 Сейчас в теме
(18) Книга оставляет противоречивое впечатление из-за своей непричёсанности. Содержание на высоком уровне, а форма — нет. Это отпугивает. Но если специалист хочет состояться как аналитик, ему придётся волевым усилием понять, что хотели сказать авторы. Это непросто, но потраченное время того стоит, и вы будете уважать себя чуть больше. Из заключения...
30. starjevschik 09.04.21 12:36 Сейчас в теме
Эти слова придуманы для больших проектов, где десятки и сотни кодеров и приходится держать большую кучу разных посторонних людей, чтобы кодеров направить в нужное русло и из их творчества можно было собрать готовый продукт.
Мелким труженикам 1с это все не нужно. Даже я б сказал вредно. Очень вредно )
Оставьте свое сообщение
Вопросы с вознаграждением