Стас Выщепан @gandjustas
Умею оптимизировать программы
Information
- Rating
- 270-th
- Location
- Москва, Москва и Московская обл., Россия
- Date of birth
- Registered
- Activity
Specialization
Software Architect, Delivery Manager
Lead
C#
.NET Core
Entity Framework
ASP.Net
Database
High-loaded systems
Designing application architecture
Git
PostgreSQL
Docker
Понял что госы. Но там другие правила игры. В отличие от бизнеса госы не заинтересованы ни в снижении затрат (бюджет все равно надо весь потратить, иначе дадут меньше), ни в увеличении прибыл (ибо нет прибыли), ни в расширении рынка (ибо нет рынка). Зато документация очень важна, потому что начальству надо бумажки показывать. И чем больше бумаги, тем лучше.
Я вот участвовал в госпроекте. Суммарные затраты на «документацию» составляли 60% бюджета проекта. При этом документация не нужна никому вообще.
Но в коммерческой разработке ни разу не было, чтобы удалось продать документацию. Обычно или заказчик сам хотел получить некоторые документ для удовлетворения внутренних регламентов или вообще отказывался от документов, понимая что в проще заключить договор поддержки (и так заключил бы), и потратить деньги на целевые нужды, чем на непонятно какую «документацию».
Кроме того под эту потребность надо будет экономическое основание писать, на слово обычно не верят. В этом случае типы документации 1-5 пролетают почти полностью, ибо ни экономии затрат, ни повышения доходов они не создают, и даже если их удастся продать, то не более чем 10% от общей суммы проекта.
Объемная документация на ПО в наше время закрывает только одну потребность — «чтобы в глазах генерала наша разработка выглядела менее солидно!». Причем состав документации в этом случае не имеет никакого значения.
Если покупатели — коммерсанты, то им в 95% случаев нафиг не нужна документация. И как бы вы не расписывали её полезность, она не закрывает реальные потребности. Если же потребности есть, то заказчик и сам попросит подготовить необходимый комплект документов.
Увидел описание причин первого порядка что результат не получен в срок и в необходимом объеме, но не ясно как выявлять причины второго порядка и что с ними делать.
А еще есть потрясающие случаи, когда человеку не хватает собранности и усидчивости. Короткие задачи он делает прекрасно, а на длинных начинает отвлекаться и постоянно движется «не туда». С одной стороны надо почти непрерывно контролировать такого работника, это микро-менеджмент, который негативно влияет как на менеджера, так и на исполнителя. А с другой стороны ослабление контроля ведет к падению производительности. При этом человек и умеет, и хочет, и может, и понял. У программистов такое встречается очень часто.
Без правильно поставленных целей создания тех или иных арртефактов все остальные аспекты не являются значимыми. Вот объясните кому нужна эта «взаимоувязанность»?
Заказчику? Он глубже ТЗ не полезет. Разработчикам? Они будут работать на уровне UC. Разве что менеджеру, которому необходимо следить чтобы результат соответствовал ТЗ. Но для этого придумали Программу и Методику Испытаний (ПМИ), которая позволяет проверить, что результат соответствует ТЗ. Тогда «взаимоувязка» ТЗ и UC не играет никакой роли.
ГОСТы кстати не лохи придумали. Стоит почаще к содержательной части гостов обращаться. Увы многие смотрят только на оформительскую часть.
2) Техническое задание — в основном если требует заказчик. Пишет аналитик и архитектор.
3) Методика испытаний — пишется если заказчик дает непонятное ТЗ, пишется аналитиком.
Это входные документы, которые обычно в начале проекта разрабатываются. В принципе может не быть ничего из вышеперечисленного.
На выходе делаем то, что хочет заказчик. Чаще всего вместо руководств пользователя пишем очень краткую инструкцию (максимум А4 на функцию) и записываем видео как ей пользоваться.
Внутренних документов нет. Все ведется в TFS.
Еще на доске рисуем иногда. Доску все видят — хорошо помогает.
Вообще самое понятие проектной документации заключается в том, что документы являются некоторым результатом проекта (артефактами), наряду с некоторым продуктом\изделием\программой. Багрепорты такими артефактами не являются, они никому не нужны за пределами проекта. Use Case из трекера тоже. Тест планы тоже зачастую никакой пользы не несут после того, как ими закончили пользоваться. Это все инструменты управления, как и почта, пересылаемая между сотрудниками. Вы же почту в документацию не записали.
Тоже можно сделать по старым функциям. День подготовки каждого человека, на выходе 5-8 часов видео со всей архитектурой системы и расшаренный опыт на всю команду + прокаченные presentation skills.
Не пишите текст, как только суммарный объем перевалит за 30 страниц плотного теста читать это никто не будет.
Также у вас не написано для кого пишется документация и кто её пишет. Это сводит полезность поста почти к нулю.
Может быть в голове у вас мысли верные есть, я не берусь это анализировать. Но изложить эти мысли вы не смогли.
Что, кстати, довольно странно учитывая вашу фразу:
Точно? У вас указано 7 типов документов, из которых 4 это текстовые файлы. По крайней мере других представлений для ТЗ, ЧТЗ и инструкций в дикой природе я не видел.
Use Case и Bug Report вообще не являются документированием, тем не менее вы про них пишите.
Только документация в этом не помогает. Помогает трекинг-система, в которой можно описывать связанные UC, задачи, баги и тест-кейсы. Сама по себе документация этому мешает, ибо лопатить большой объем документов в поиске нужных сведений и отслеживать изменения нереально. Иногда проще в коде посмотреть.
Так не бывает. Математически доказано что не бывает полной и непротиворечивой системы. Кроме того, чем больше текста и чем больше участников, тем меньше вероятность что все участники одинаково поймут все написанное.
«Красиво донести информацию» и «удобно работать» — разные вещи. Самые красивые порталы, которые я видел, были предельно непрактичны. Реальная работа велась на обычных сайтах, созданных для подразделений. По факту в 99,9% порталов удобство и красота понятия противоположные.
Учить все равно надо, потому что обучение это не только приобретение знаний, но и мотивация. Причем стандартному функционалу учить легче, ибо он везде одинаковый, даже в других компаниях. Можно использовать существующие материалы. Нестандартный интерфейс сам по себе является не преимуществом, а недостатком с точки зрения экономики.
Теперь конкретнее.
Вот вы перечислили задачи: отпуски, бронирование переговорных, документооборот.
Если надо человеку отпуск оформить, то он все равно пойдет и нажмет нужные кнопки, даже если будет стандартный интерфейс. Или надо ему переговорку забронировать, тоже сделает то что нужно. Если вы закрываете потребности людей, то они будут пользоваться тем, что вы сделали, несмотря на красоту, «дружелюбность» и «удобство». Тоже самое касается документооборота и других практических вещей. А вот если не пользуются, то два варианта — не знают или действительно не удобно. И если действительно не удобно, то это нельзя исправить просто добавлением красивостей в интерфейс.
Новостные ленты и прочая муть не нужна почти никому, кроме тех, кто за эти новости отвечает.
Чтобы у сотрудника было ощущение что сделали что-то для него, то нужна персонализация, которая вообще никаким боком не относится к «удобству».
У вас получается аж два интерфейса — основной интерфейс сайта, как на графике, и кастомная форма, которая похожа на стандартный интерфейс SharePoint 2010, но значительно переделана. Самый лучший интерфейс — стандартный. Просто потому что он везде одинаковый и везде описан. Пользователю достаточно один раз научиться работать со стандартным интерфейсом и он сможет им пользоваться везде, независимо от того, что вы внутри напрограммируете.
Кастом нужен в двух случаях — а) создать вау-эффект, это 1-2 страницы портала, б) оптимизировать под конкретный сценарий, например отметка на карте вместо ввода координат в форме. В остальных случаях лучше стандартный, особенно с точки зрения экономической эффективности.
То что блок для многочего вообще не является оправданием. Отпусками пользуются люди 2-3 раза в год в среднем. Переговорками от 2-3 раз в месяц. То есть минимум в 12 раз чаще (!). Кроме этого переговорки обычно бронируют из exchange, у него кстати есть web access, так что веб интерфейс на шарике не сильно нужен.
Что по поводу SSIS, то проблем никаких нет сделать тупо цикл внутри пакета, который будет бежать по всем спискам отпусков. А на корневом узле сделать скрытый список списков или доставать их поиском. Так что нет необходимости поддерживать более одного пакета.
ИМХО ваше решение, как и подавляющее большинство других, не оптимально с точки зрения экономики, при использовании SharePoint. Кстати, что, из того что вы сделали, требует именно SharePoint?
Я вот делал заявки на отпуск, сделал тупо список с полями и стандартный процесс согласования. Причем работает он на сайте отдела, никаких дополнительных разграничений доступа не надо. Люди из другого отдела и не увидят, если им явно доступ не дать. (это к первому комменту).
Дальше список сохраняется как шаблон и размножается на N отделов, каждому настраивается свой процесс за 5 минут.
Дальше если понадобится куда-то интегрировать, то я возьму SSIS, который умеет переливать данные. А для дополнительных проверок тупо напишу event receiver или сделаю логику в workflow.
ИМХО именно так надо делать решения на шарике, а не струячить код, формы и прочие интеграции.