Я думаю что вводить KPI для программистов — попытка решить проблему которой или вообще нет, или её никто не понимает.
Большая часть программистов уже мотивирована писать код и основная задача менеджмента — не мешать им это делать. Можно еще повышать интерес обучениями и поездками на конференцию.
Измерять кто пишет лучше, а кто хуже — очень сложно, слишком много нелинейных факторов. Только на очень типовых проектах можно ввести подобие нормирования, и то не всегда такая система работает.
А вот что действительно нужно мотивировать, так это командную работу. Очень хорошо работают проектные премии в этом случае. При этом премия должна быть значительной.
Кстати это не значит, что не надо контролировать продуктивность. В идеале надо иметь софт для учета времени сотрудников, и если кто-то сильно отклоняется от типового поведения программистов, то это повод поговорить «по душам». При этом сотрудник не обязательно должен находится в офисе, можно и удаленных также контролировать. НО НЕЛЬЗЯ ПРИВЯЗЫВАТЬ УРОВЕНЬ ЗП К ЭТОЙ МЕТРИКЕ.
Такое наблюдается если сотрудники не видят связи между усилиями и результатами. Но для ПМов прямая привязка к финансовым результатам (в случае заказных проектов разработки ПО) очень даже прозрачную схему дает.
А вы и так придете к этому варианту, когда захотите исправить ситуацию. Ибо на позиции менеджера очень удобно делегировать ответственность, оставаясь ни в чем не виноватым. Ничем, кроме прямой мотивации от результата проекта, это не получится исправить.
Просто сделайте премию РП функцией от рентабельности проекта\продукта, которым он занимается и все само станет на свои места. А еще лучше при этом удвоить нагрузку на каждого, разгонав половину самыми низкими KPI.
Если есть проекты, на которых компания инвестирует деньги, а не получает, то за них назначайте отдельные премии обратно пропорциональные затратам.
Кто вам это говорил? Мне вот довелось общаться с пользователями. Они даже говорили такие слова, но на вопрос «зачем?» ответить не смогли. Просто увидели функционал где-то. После выявления реальных потребностей оказывалось, что оно им совсем не нужно.
На этом думаю можно закончить. Пока вы не сможете использовать возможности, перечисленные выше вы вряд ли научитесь делать нормальные решения.
Еще раз повторю, решения на Foundation обычно повторяют функционал Server. Впаривать их со словами что «стандартный так не умеет и вообще у нас все особенное» — обман. Я не против доделывать шарик, я говорю что можно доделывать на порядок дешевле.
Какому, простите, законодательству? Приведите номера законов, обязательных для выполнения коммерческими структурами, которые требуют кастомизации шарика? Про ЭЦП и юридически значимый ДО не надо, мы не про нее говорим, мы говорим про внутренний документооборот.
ЭЦП внутри организации не нужен. Нет ни одного закона, который требует юридически значимый документооборот внутри компании. Это тоже обман, но уже в совсем другой области.
Не переводите тему. Вы же сами написали про две конкретные (и видимо самые насущные) задачи. Оказывается там не нужна кастомизация. Далее вы начинаете вилять, приплетая ЭЦП (зачем она не ясно), межведомственный ДО (который только у госов и вообще другая тема, в которой Ростелеком сидит), exchange, от которого «устали» аж две (из тысяч) компании, которым, скорее всего, чето вроде project server нужно было.
Давайте останемся в поле, которое вы изначально определили — электронный ДО (не электронно-бумажный как в госах) + мелкие портальные функции 80к документов и связанных элементов по которым надо искать.
Вы будете продолжать утверждать, что решение с кучей кастома на Foundation выгоднее для заказчика, чем Server? особенно с учетом скидок на лицензии.
Ну да, конечно. Вы обманываете заказчиков, а я не разобрался в вопросе.
«настоящий российский документооборот» это госы? Я делал документооборот в коммерческих структурах, описанных проблем не было. У госов есть другая проблема, им в принципе не нужна СЭД, у них документооборот преимущественно бумажный. Им нужна база учета-движения бумажек, а не СЭД.
Еще иногда система поручений из-за директивного метода управления, она закрывается тупо exchange, в нем есть все чтобы создавать и делегировать задачи. При небольшом кодинге можно вытаскивать отчет об исполнительской дисциплине.
16 часов это на решение одной задачи, и это много. Большинство полезных вещей в шарике можно сделать за час-два. Погружение в кодинг увеличивает время в десятки и сотни раз и чаще всего финансово неоправдано.
Скидку взял у МС.
Тиражируемое решение или нет — неважно, вы предлагаете решение проблем, которые и без вашего продукта отлично решаются. Это по сути обман покупателя, построенный на асимметричности информации.
Почему покупают — написал в посте, я миллион раз слышал ушлых продавцов решений, которые рассказывали, что шарик четотам не умеет.
ЗЫ. Я тестил хренов тучу решений, а также ковырял, смотрел как сделано внутри. Увы большинство решений полнейший отстой. EOS for SharePoint это отстой в кубе. Кстати своим постом про Service App вы это очень хорошо показали ;)
10 страниц в секунду дают около 140 rps, причем статики там немного. Вопрос не в скорости самого SharePoint, а в том что он делает. Можно вообще положить голый HTML на сервер и радоваться тысячам RPS. Вот только что они вам дадут в реальной жизни? Когда надо из 10к документов вытащить топ 10 по динамическому рейтингу (который нельзя просто хранить, надо считать) это все с учетом прав текущего пользователя?
Я видел подобную систему на супер-пупер-быстром asp.net. Валилась она на 5 пользователях, каждая страница генерилась по 15-20 секунд, очередь IIS быстро переполнялась.
У нас есть портальчик, который держит 10 запросов в секунду на WFE, при этом имеет базу в 2 ТБ и на главной странице (60% запросов) делает в выборки последних новостей\картинок\видео итп с таргетингом по региону пользователя, учитывая права доступа. Открывается за 2-3 секунуды при этом. И это еще не предел оптимизации.
масштабируемость (приложение-службу можно размещать на нескольких серверах);
Я вас расстрою, но в таком виде ваше приожение-службу нельзя размещать на нескольких серверах. Я не вижу чтобы ваш ServiceApplication реализовывал интерфейс веб-сервиса, и код в эвент-ресивере, скорее всего, лезет непосредственно в базу
Я один не понял зачем чето во внешнюю базу выгружать? Отчеты сделать? Тогда зачем все эти пляски с ServiceApp, проще взять SSIS и выгрузить данные в список с помощью sqlsrvintegrationsrv.codeplex.com/releases/view/17652. Дальше поставить Reporting Services в режиме интеграции и налепить отчеты. Кастомного кода в SharePoint будет ровно ноль.
В самом SharePoint эффективно использовать поиск для построения выборок по большому объему данных, он, в отличие от кастомной базы, учитывает права на элементы. Если у вас SharePoint Enterprise, то это тоже не требует кастомного кода.
В принципе не понимаю зачем нужно покупать любой продукт типа XXX for SharePoint, почти все можно сделать средствами изкаропки. А что нельзя требует небольших локальных доработок.
Кстати вы путаете бюрократию и коррупцию.
Большая часть программистов уже мотивирована писать код и основная задача менеджмента — не мешать им это делать. Можно еще повышать интерес обучениями и поездками на конференцию.
Измерять кто пишет лучше, а кто хуже — очень сложно, слишком много нелинейных факторов. Только на очень типовых проектах можно ввести подобие нормирования, и то не всегда такая система работает.
А вот что действительно нужно мотивировать, так это командную работу. Очень хорошо работают проектные премии в этом случае. При этом премия должна быть значительной.
Кстати это не значит, что не надо контролировать продуктивность. В идеале надо иметь софт для учета времени сотрудников, и если кто-то сильно отклоняется от типового поведения программистов, то это повод поговорить «по душам». При этом сотрудник не обязательно должен находится в офисе, можно и удаленных также контролировать. НО НЕЛЬЗЯ ПРИВЯЗЫВАТЬ УРОВЕНЬ ЗП К ЭТОЙ МЕТРИКЕ.
Если есть проекты, на которых компания инвестирует деньги, а не получает, то за них назначайте отдельные премии обратно пропорциональные затратам.
1) sptypescript.codeplex.com/SourceControl/latest#SPTypeScript/Sample_FieldLookupBySearch/ Сделал за день. Допилить до нужной кондиции еще день.
2) Честное разграничение прав по полям в шарике не сделаешь. На уровне UI легко можно, из этого же репозитария: sptypescript.codeplex.com/SourceControl/latest#SPTypeScript/Sample_CSRComplexityField/
3) Отдельные папки\списки\сайты и поиск. Ограничения «хитрее», чем даются платформой не сделаешь, или это будут не ограничения, а фикция.
4)Встроенный WF, возможно потребуется добавить несколько workflow action, у меня создание сложного WFAction заняло 4 часа.
5)Встроенный список задач в SP 2013
6)бла-бла-бла. слова ни о чем.
На этом думаю можно закончить. Пока вы не сможете использовать возможности, перечисленные выше вы вряд ли научитесь делать нормальные решения.
Еще раз повторю, решения на Foundation обычно повторяют функционал Server. Впаривать их со словами что «стандартный так не умеет и вообще у нас все особенное» — обман. Я не против доделывать шарик, я говорю что можно доделывать на порядок дешевле.
ЭЦП внутри организации не нужен. Нет ни одного закона, который требует юридически значимый документооборот внутри компании. Это тоже обман, но уже в совсем другой области.
Не переводите тему. Вы же сами написали про две конкретные (и видимо самые насущные) задачи. Оказывается там не нужна кастомизация. Далее вы начинаете вилять, приплетая ЭЦП (зачем она не ясно), межведомственный ДО (который только у госов и вообще другая тема, в которой Ростелеком сидит), exchange, от которого «устали» аж две (из тысяч) компании, которым, скорее всего, чето вроде project server нужно было.
Давайте останемся в поле, которое вы изначально определили — электронный ДО (не электронно-бумажный как в госах) + мелкие портальные функции 80к документов и связанных элементов по которым надо искать.
Вы будете продолжать утверждать, что решение с кучей кастома на Foundation выгоднее для заказчика, чем Server? особенно с учетом скидок на лицензии.
«настоящий российский документооборот» это госы? Я делал документооборот в коммерческих структурах, описанных проблем не было. У госов есть другая проблема, им в принципе не нужна СЭД, у них документооборот преимущественно бумажный. Им нужна база учета-движения бумажек, а не СЭД.
Еще иногда система поручений из-за директивного метода управления, она закрывается тупо exchange, в нем есть все чтобы создавать и делегировать задачи. При небольшом кодинге можно вытаскивать отчет об исполнительской дисциплине.
16 часов это на решение одной задачи, и это много. Большинство полезных вещей в шарике можно сделать за час-два. Погружение в кодинг увеличивает время в десятки и сотни раз и чаще всего финансово неоправдано.
Скидку взял у МС.
Тиражируемое решение или нет — неважно, вы предлагаете решение проблем, которые и без вашего продукта отлично решаются. Это по сути обман покупателя, построенный на асимметричности информации.
Почему покупают — написал в посте, я миллион раз слышал ушлых продавцов решений, которые рассказывали, что шарик четотам не умеет.
ЗЫ. Я тестил хренов тучу решений, а также ковырял, смотрел как сделано внутри. Увы большинство решений полнейший отстой. EOS for SharePoint это отстой в кубе. Кстати своим постом про Service App вы это очень хорошо показали ;)
Я видел подобную систему на супер-пупер-быстром asp.net. Валилась она на 5 пользователях, каждая страница генерилась по 15-20 секунд, очередь IIS быстро переполнялась.
Я вас расстрою, но в таком виде ваше приожение-службу нельзя размещать на нескольких серверах. Я не вижу чтобы ваш ServiceApplication реализовывал интерфейс веб-сервиса, и код в эвент-ресивере, скорее всего, лезет непосредственно в базу
В самом SharePoint эффективно использовать поиск для построения выборок по большому объему данных, он, в отличие от кастомной базы, учитывает права на элементы. Если у вас SharePoint Enterprise, то это тоже не требует кастомного кода.
В принципе не понимаю зачем нужно покупать любой продукт типа XXX for SharePoint, почти все можно сделать средствами изкаропки. А что нельзя требует небольших локальных доработок.