Pull to refresh
59
29
Стас Выщепан @gandjustas

Умею оптимизировать программы

Send message
Сначала хотел откомментить все, но потом прочитал это:
В последние несколько лет мне редко доводится участвовать в проектах с бюджетом менее 100 млн. рублей

Понял что госы. Но там другие правила игры. В отличие от бизнеса госы не заинтересованы ни в снижении затрат (бюджет все равно надо весь потратить, иначе дадут меньше), ни в увеличении прибыл (ибо нет прибыли), ни в расширении рынка (ибо нет рынка). Зато документация очень важна, потому что начальству надо бумажки показывать. И чем больше бумаги, тем лучше.

Я вот участвовал в госпроекте. Суммарные затраты на «документацию» составляли 60% бюджета проекта. При этом документация не нужна никому вообще.

Но в коммерческой разработке ни разу не было, чтобы удалось продать документацию. Обычно или заказчик сам хотел получить некоторые документ для удовлетворения внутренних регламентов или вообще отказывался от документов, понимая что в проще заключить договор поддержки (и так заключил бы), и потратить деньги на целевые нужды, чем на непонятно какую «документацию».
В отличие от b2c рынка, где потребность можно создать за счет эмоций и сиюминутности, на b2b рынке для создания потребности надо вложить очень много денег, и то не факт что получится.
Кроме того под эту потребность надо будет экономическое основание писать, на слово обычно не верят. В этом случае типы документации 1-5 пролетают почти полностью, ибо ни экономии затрат, ни повышения доходов они не создают, и даже если их удастся продать, то не более чем 10% от общей суммы проекта.
Надо было начать с истории, которая в конце… и ей же закончить.

Объемная документация на ПО в наше время закрывает только одну потребность — «чтобы в глазах генерала наша разработка выглядела менее солидно!». Причем состав документации в этом случае не имеет никакого значения.

Если покупатели — коммерсанты, то им в 95% случаев нафиг не нужна документация. И как бы вы не расписывали её полезность, она не закрывает реальные потребности. Если же потребности есть, то заказчик и сам попросит подготовить необходимый комплект документов.
То есть описанные причины не являются исчерпывающими для определения в чем проблема? И как же в этом случае ответить на вопрос «как раскачать low performer_а»?
Прочитал статью дважды, но не нашёл ответа на вопрос из заголовка: “Как раскачать low-performer’а”
Увидел описание причин первого порядка что результат не получен в срок и в необходимом объеме, но не ясно как выявлять причины второго порядка и что с ними делать.

А еще есть потрясающие случаи, когда человеку не хватает собранности и усидчивости. Короткие задачи он делает прекрасно, а на длинных начинает отвлекаться и постоянно движется «не туда». С одной стороны надо почти непрерывно контролировать такого работника, это микро-менеджмент, который негативно влияет как на менеджера, так и на исполнителя. А с другой стороны ослабление контроля ведет к падению производительности. При этом человек и умеет, и хочет, и может, и понял. У программистов такое встречается очень часто.
Большего бреда в жизни не читал. Есть отдельные правильные моменты, но нет даже попытки разобраться в причинах. Это в свою очередь ведет к неверным выводам.
Исходный код получается тоже является документированием? А email? Или сообщения в чате? Получается что все что делается — документирование. Это как-то расходится с общепринятой терминологией.

Без правильно поставленных целей создания тех или иных арртефактов все остальные аспекты не являются значимыми. Вот объясните кому нужна эта «взаимоувязанность»?
Заказчику? Он глубже ТЗ не полезет. Разработчикам? Они будут работать на уровне UC. Разве что менеджеру, которому необходимо следить чтобы результат соответствовал ТЗ. Но для этого придумали Программу и Методику Испытаний (ПМИ), которая позволяет проверить, что результат соответствует ТЗ. Тогда «взаимоувязка» ТЗ и UC не играет никакой роли.

ГОСТы кстати не лохи придумали. Стоит почаще к содержательной части гостов обращаться. Увы многие смотрят только на оформительскую часть.
Какое описание? В TFS есть стори, таски, баги. Это не документы. Они неотчуждаемы.
1) Концепция — на этапе пресейла, если проект большой. Фиксирует заинтересованные стороны, бизнес-цели, верхнеуровневую архитектуру. Пишет аналитик и немного архитектор.
2) Техническое задание — в основном если требует заказчик. Пишет аналитик и архитектор.
3) Методика испытаний — пишется если заказчик дает непонятное ТЗ, пишется аналитиком.

Это входные документы, которые обычно в начале проекта разрабатываются. В принципе может не быть ничего из вышеперечисленного.

На выходе делаем то, что хочет заказчик. Чаще всего вместо руководств пользователя пишем очень краткую инструкцию (максимум А4 на функцию) и записываем видео как ей пользоваться.

Внутренних документов нет. Все ведется в TFS.
Еще на доске рисуем иногда. Доску все видят — хорошо помогает.
ТЗ в первую и последнюю очередь пишется для согласования с заказчиком. Если такого нет, то списка Use Case сгруппированного по Epic и Theme более чем достаточно. Для ТЗ и ЧТЗ есть определенный формат описания (текстового), как в России, так и за рубежом. Естественно заказчик будет согласовывать текстовый документ, а не что-то-там в трекере.

Вообще самое понятие проектной документации заключается в том, что документы являются некоторым результатом проекта (артефактами), наряду с некоторым продуктом\изделием\программой. Багрепорты такими артефактами не являются, они никому не нужны за пределами проекта. Use Case из трекера тоже. Тест планы тоже зачастую никакой пользы не несут после того, как ими закончили пользоваться. Это все инструменты управления, как и почта, пересылаемая между сотрудниками. Вы же почту в документацию не записали.
Самый лучший способ — берете разработчика, который только что поставил новую функцию. Не просто закодил, а функция попала к заказчику и прошла проверку реальными пользователями. Пусть сделает по ней презентацию минут на 15, со сладами, выступлением и ответами на вопросы коллег. Это все запишите на видео.

Тоже можно сделать по старым функциям. День подготовки каждого человека, на выходе 5-8 часов видео со всей архитектурой системы и расшаренный опыт на всю команду + прокаченные presentation skills.

Не пишите текст, как только суммарный объем перевалит за 30 страниц плотного теста читать это никто не будет.
В отличие от вас у него очень четко описано какая документация и зачем пишется. А у вас этого нет.
Также у вас не написано для кого пишется документация и кто её пишет. Это сводит полезность поста почти к нулю.

Может быть в голове у вас мысли верные есть, я не берусь это анализировать. Но изложить эти мысли вы не смогли.
Что, кстати, довольно странно учитывая вашу фразу:
Я бизнес-аналитик, уже десять лет работаю в области разработки заказного программного обеспечения, в последнее время совмещаю роли аналитика и руководителя проектов.
По документом я подразумеваю не текстовый файл

Точно? У вас указано 7 типов документов, из которых 4 это текстовые файлы. По крайней мере других представлений для ТЗ, ЧТЗ и инструкций в дикой природе я не видел.

Это уже несколько другой вопрос, касающийся, скорее, управления проектом, чем документирования.

Use Case и Bug Report вообще не являются документированием, тем не менее вы про них пишите.
Вот почитайте мысли очень опытного ПМа и просто грамотного человека на тему документации — gaperton.livejournal.com/60632.html
Вот у вас описаны цели:
1. Документация обеспечивает «общее пространство» проекта.
2. Команда говорит «на одном языке».
3. Документирование позволяет четко разграничить зоны ответственности между участниками проекта.


Только документация в этом не помогает. Помогает трекинг-система, в которой можно описывать связанные UC, задачи, баги и тест-кейсы. Сама по себе документация этому мешает, ибо лопатить большой объем документов в поиске нужных сведений и отслеживать изменения нереально. Иногда проще в коде посмотреть.

Только тщательно описанные требования могут быть проверены на полноту и непротиворечивость

Так не бывает. Математически доказано что не бывает полной и непротиворечивой системы. Кроме того, чем больше текста и чем больше участников, тем меньше вероятность что все участники одинаково поймут все написанное.
От того что вы 6 раз повторите «удобный» в разных формах, портал удобнее не станет. Я не глупый заказчик, на меня это не действует.

«Красиво донести информацию» и «удобно работать» — разные вещи. Самые красивые порталы, которые я видел, были предельно непрактичны. Реальная работа велась на обычных сайтах, созданных для подразделений. По факту в 99,9% порталов удобство и красота понятия противоположные.

Учить все равно надо, потому что обучение это не только приобретение знаний, но и мотивация. Причем стандартному функционалу учить легче, ибо он везде одинаковый, даже в других компаниях. Можно использовать существующие материалы. Нестандартный интерфейс сам по себе является не преимуществом, а недостатком с точки зрения экономики.

Теперь конкретнее.
Вот вы перечислили задачи: отпуски, бронирование переговорных, документооборот.
Если надо человеку отпуск оформить, то он все равно пойдет и нажмет нужные кнопки, даже если будет стандартный интерфейс. Или надо ему переговорку забронировать, тоже сделает то что нужно. Если вы закрываете потребности людей, то они будут пользоваться тем, что вы сделали, несмотря на красоту, «дружелюбность» и «удобство». Тоже самое касается документооборота и других практических вещей. А вот если не пользуются, то два варианта — не знают или действительно не удобно. И если действительно не удобно, то это нельзя исправить просто добавлением красивостей в интерфейс.

Новостные ленты и прочая муть не нужна почти никому, кроме тех, кто за эти новости отвечает.

Чтобы у сотрудника было ощущение что сделали что-то для него, то нужна персонализация, которая вообще никаким боком не относится к «удобству».
Эти НО обычно выдумываю разработчики.

У вас получается аж два интерфейса — основной интерфейс сайта, как на графике, и кастомная форма, которая похожа на стандартный интерфейс SharePoint 2010, но значительно переделана. Самый лучший интерфейс — стандартный. Просто потому что он везде одинаковый и везде описан. Пользователю достаточно один раз научиться работать со стандартным интерфейсом и он сможет им пользоваться везде, независимо от того, что вы внутри напрограммируете.
Кастом нужен в двух случаях — а) создать вау-эффект, это 1-2 страницы портала, б) оптимизировать под конкретный сценарий, например отметка на карте вместо ввода координат в форме. В остальных случаях лучше стандартный, особенно с точки зрения экономической эффективности.

То что блок для многочего вообще не является оправданием. Отпусками пользуются люди 2-3 раза в год в среднем. Переговорками от 2-3 раз в месяц. То есть минимум в 12 раз чаще (!). Кроме этого переговорки обычно бронируют из exchange, у него кстати есть web access, так что веб интерфейс на шарике не сильно нужен.

Что по поводу SSIS, то проблем никаких нет сделать тупо цикл внутри пакета, который будет бежать по всем спискам отпусков. А на корневом узле сделать скрытый список списков или доставать их поиском. Так что нет необходимости поддерживать более одного пакета.

ИМХО ваше решение, как и подавляющее большинство других, не оптимально с точки зрения экономики, при использовании SharePoint. Кстати, что, из того что вы сделали, требует именно SharePoint?
У вас кастомные формы и внешняя база, зачем вам SharePoint?

Я вот делал заявки на отпуск, сделал тупо список с полями и стандартный процесс согласования. Причем работает он на сайте отдела, никаких дополнительных разграничений доступа не надо. Люди из другого отдела и не увидят, если им явно доступ не дать. (это к первому комменту).

Дальше список сохраняется как шаблон и размножается на N отделов, каждому настраивается свой процесс за 5 минут.

Дальше если понадобится куда-то интегрировать, то я возьму SSIS, который умеет переливать данные. А для дополнительных проверок тупо напишу event receiver или сделаю логику в workflow.

ИМХО именно так надо делать решения на шарике, а не струячить код, формы и прочие интеграции.

Технический долг сам по себе проблемой не является. Проблемы начинаются на поддержке. В итоге при неправильном распределении усилий технический долг в первую очередь съест премию самого ПМа.

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