Возможно, имело смысл ввести лимиты на количество поручений, как для входящих так и для исходящих, особенно для горизонтальных.
Также было бы интересным добавить автокластеризацию текстов поручений, отслеживание длин цепочек поручений и периодичность. Составить частотные словари по группам пользователей, добавить в систему ботов.
«Основная задача персональных вычислений — формализация профессиональных знаний — выполняется, как правило, полностью самостоятельно непрограммирующим профессионалом или при минимальной технической поддержке программиста, который в этом случае имеет возможность включаться в процесс формализации знаний только на инструментальном уровне, оставляя наиболее трудную для его понимания содержательную часть задачи специалисту в данной предметной области.» (ТЕХНОЛОГИЯ АВТОФОРМАЛИЗАЦИИ ПРОФЕССИОНАЛЬНЫХ ЗНАНИЙ Г.Р.Громов.)
Дело в том, что разработчик на платформе 1С — это и есть «непрограммирующий профессионал», а, следовательно, он обязан понимать содержательную часть задачи предметной области и решать основную задачу персональных вычислений. Противоречие возникает в тех случаях, когда специалист 1С забывает о том, что «формализм» это целиком его зона ответственности.
Методология учета, консультации и обучение пользователей также относятся к компетенции специалистов 1С. Понятно, что «истина всегда конкретна» и каждое внедрение ПО требует индивидуального подхода к клиенту, но тем не менее, всегда полезно соблюдать базовые принципы. Консультации и обучение, — почасовые услуги без ТЗ. Настройка типового решения 1С, — почасовые услуги без ТЗ. При разработке отраслевого решения на платформе 1С, необходимо соблюдать официальный перечень требований 1С, включающий требования к документации.
К сожалению, иногда происходит подмена понятий — логическая ошибка, заключающаяся в выдаче какого-либо программного продукта за решение, каким он заведомо не является, и в использовании несоответствующих контексту задачи определений.
Суррогат и формализм — это подмена понятий. Сам термин «формализм» не несет негативного смысла, даже напротив, в контексте программной разработки формализм напрямую связан с формальной логикой и дедукцией, для которой характерны: непротиворечивость, полнота, независимость, разрешимость. Формальное описание предметной области весьма ценно. В какой форме оптимально фиксировать формализованные знания это отдельный вопрос. Кому-то нравится спецификация через тестирование, кому-то списки требований в екселе, кто-то зачарован диаграммами UML простор тут большой. К большому сожалению, многие ограничиваются заметками в msword, в запущенных случаях по ГОСТ-34.
Но есть же native addons — берешь и пишешь себе прикладной объект, по-взрослому на c++.
Главное придумать что за новый вид прикладного объекта нужен, а его реализация это не такая большая проблема. Если нужно чтобы «свой прикладной объект» работал с базой, то есть webservice и json.
Не понимаю, что за проблема, чего не хватает. Какие прикладные объекты вы бы хотели добавить?
Ба! Да это же Зиман применение теории особенностей Уитни.
Пример из синей книжки В. Арнольда.
Модель «ученый» в пространстве «техника — увлеченность — достижения».
достижения = эффективность
мотивированность = увлеченность
Только отсутствует измерение: «техника = скиллы».
Cпасибо автору за теплые ламповые графики.
p.s.
за подробностями: search?q=зиман+уитни+гении+маньяки
Какие нехорошие люди, жадные. Лучше с такими не работать.
Если повезло найти экспертов из другой области, то нужно всегда стараться наладить
взаимопонимание и прислушиваться к их советам. Таких людей ценят.
Главное чтобы было в принципе возможно «взять языка» в стане заказчика, а то может так оказаться, что достаточно компетентных сотрудников у заказчика просто нет и грамотно сформулировать требования к разработке просто некому.
Тогда от BA потребуется не просто сбор и фиксация требований, а навыки методиста и консультанта по специфике предметной области заказчика, что на практике чаще всего и требуется. Соответственно и вопрос с оплатой за услуги BA решается гораздо проще.
Вообще, конечно это иллюзия, что вы можете просто так взять и впереться на любой сегмент рынка, не зная его специфики и находу, в каких-то там опросниках, на коленке в переговорке составить исчерпывающее техническое задание.
Проблема в том, что в сфере оказания услуг по настройке
ПО фирмы 1С имеет место систематическая подмена понятий.
Писать надо было в договоре:
Исполнитель обязуется оказать следующий перечень услуг:
1) консультационные услуги в объеме x часов
отв.: Иванов И.И. (1С: Специалист-консультант по прикладным решениям «1С: Предприятие 8» )
2) услуги в объеме y часов по настройке конфигурации такой-то
Отв.:
2.1 Петров П.П. (Специалист" по платформе «1С: Предприятие 8»)
2.2 Сидоров С.С. (1С Специалист по конфигурации такой-то)
3) информационно-технологическая поддержка, период: столько-то месяцев
Отв.:
ФИО ( профессионал по ...)
Копии сертификатов в приложении № таком-то
А то развели антимонию, понимашь: «ТЗ», «по госту».
Это же не сишечка, никакого выхлопа в виде «составного программного продукта», вам принадлежащего у вас нет.
Сейчас приходится писать так:
Хочется, чтобы было так:
как в питоне:
Лямбды хочется, да…
Также было бы интересным добавить автокластеризацию текстов поручений, отслеживание длин цепочек поручений и периодичность. Составить частотные словари по группам пользователей, добавить в систему ботов.
tests: django; fabric3
СПАСИБО
Дело в том, что разработчик на платформе 1С — это и есть «непрограммирующий профессионал», а, следовательно, он обязан понимать содержательную часть задачи предметной области и решать основную задачу персональных вычислений. Противоречие возникает в тех случаях, когда специалист 1С забывает о том, что «формализм» это целиком его зона ответственности.
Методология учета, консультации и обучение пользователей также относятся к компетенции специалистов 1С. Понятно, что «истина всегда конкретна» и каждое внедрение ПО требует индивидуального подхода к клиенту, но тем не менее, всегда полезно соблюдать базовые принципы. Консультации и обучение, — почасовые услуги без ТЗ. Настройка типового решения 1С, — почасовые услуги без ТЗ. При разработке отраслевого решения на платформе 1С, необходимо соблюдать официальный перечень требований 1С, включающий требования к документации.
К сожалению, иногда происходит подмена понятий — логическая ошибка, заключающаяся в выдаче какого-либо программного продукта за решение, каким он заведомо не является, и в использовании несоответствующих контексту задачи определений.
Суррогат и формализм — это подмена понятий. Сам термин «формализм» не несет негативного смысла, даже напротив, в контексте программной разработки формализм напрямую связан с формальной логикой и дедукцией, для которой характерны: непротиворечивость, полнота, независимость, разрешимость. Формальное описание предметной области весьма ценно. В какой форме оптимально фиксировать формализованные знания это отдельный вопрос. Кому-то нравится спецификация через тестирование, кому-то списки требований в екселе, кто-то зачарован диаграммами UML простор тут большой. К большому сожалению, многие ограничиваются заметками в msword, в запущенных случаях по ГОСТ-34.
Главное придумать что за новый вид прикладного объекта нужен, а его реализация это не такая большая проблема. Если нужно чтобы «свой прикладной объект» работал с базой, то есть webservice и json.
Не понимаю, что за проблема, чего не хватает. Какие прикладные объекты вы бы хотели добавить?
Начинать надо с изучения сегмента рынка на котором
собираешься работать. Сбор информации, анализ.
Идти на встречу с заказчиком желательно после
синтеза собственного видения проблемной области.
В идеале — прототипировать пару-тройку экранов, еще лучше
это сделать совместно с дизайнером, чтобы глаз радовало.
Имея на руках презентацию и прототип легче перевести разговор с заказчиком
в конструктивное русло. На самом деле, рынки уже сложились.
Обзоры есть в продаже. Нормативная база также. Часть инфы гуглится.
Нарабатывать базу прототипов можно и заранее, не дожидаясь
звонков от клиентов. Добавлю, что автору удалось в статье очень логично
и талантливо в рамках своей собственной уникальной системы понятий описать процесс коммуникации
с клиентом, но к техническому заданию, как к регламентному документу
это не имеет отношения. Скорее протоколы, спецификации, психологические заметки,
но не ТЗ.
Пример из синей книжки В. Арнольда.
Модель «ученый» в пространстве «техника — увлеченность — достижения».
достижения = эффективность
мотивированность = увлеченность
Только отсутствует измерение: «техника = скиллы».
Cпасибо автору за теплые ламповые графики.
p.s.
за подробностями: search?q=зиман+уитни+гении+маньяки
Если повезло найти экспертов из другой области, то нужно всегда стараться наладить
взаимопонимание и прислушиваться к их советам. Таких людей ценят.
Тогда от BA потребуется не просто сбор и фиксация требований, а навыки методиста и консультанта по специфике предметной области заказчика, что на практике чаще всего и требуется. Соответственно и вопрос с оплатой за услуги BA решается гораздо проще.
Вообще, конечно это иллюзия, что вы можете просто так взять и впереться на любой сегмент рынка, не зная его специфики и находу, в каких-то там опросниках, на коленке в переговорке составить исчерпывающее техническое задание.
ПО фирмы 1С имеет место систематическая подмена понятий.
Писать надо было в договоре:
Исполнитель обязуется оказать следующий перечень услуг:
1) консультационные услуги в объеме x часов
отв.: Иванов И.И. (1С: Специалист-консультант по прикладным решениям «1С: Предприятие 8» )
2) услуги в объеме y часов по настройке конфигурации такой-то
Отв.:
2.1 Петров П.П. (Специалист" по платформе «1С: Предприятие 8»)
2.2 Сидоров С.С. (1С Специалист по конфигурации такой-то)
3) информационно-технологическая поддержка, период: столько-то месяцев
Отв.:
ФИО ( профессионал по ...)
Копии сертификатов в приложении № таком-то
А то развели антимонию, понимашь: «ТЗ», «по госту».
Это же не сишечка, никакого выхлопа в виде «составного программного продукта», вам принадлежащего у вас нет.
Для opensource проектов бесплатно или только кредит 10$?