Комментарии / Профиль projectmaker

08.02.2023 09:04:40

Wed, 08 Feb 2023 09:04:40 GMT

По факту получается следующее: на стратегическом уровне, уровне разработки базы и ключевых расчетных механизмов - обычная проектная технология а-ля ГОСТ34. А когда переходишь на стадию внедрения, то начинается куча мелких и не очень доработок уже по факту поступления запросов от пользователей или от членов команды, которые видят, что получается не то, что хотели.

Поверьте, за Яндекс.Карты - это очень сложный Инструмент: создать карты по спутниковым снимкам, склеить квадратики, начертить граф дорог, создать изображения для разных масштабов (генерализация), создать базу объектов и нанести их на карту. Это огромная работа. То есть Продукт - это только внешняя и очень малая часть Инструмента. Продукт без Инструмента работать не будет, даже Youtube.

26.02.2019 12:48:41

Tue, 26 Feb 2019 12:48:41 GMT

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

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

21.12.2018 12:30:08

Fri, 21 Dec 2018 12:30:08 GMT

Спасибо. Учту.

21.12.2018 06:30:29

Fri, 21 Dec 2018 06:30:29 GMT

Насчет «легко и просто» — это можно сказать маркетинговый ход, чтобы заголовок привлекал. Конечно, составление ТЗ — тяжкий труд. Да и вообще разобраться в ГОСТ 34 сложно: не потому, что ГОСТ плохой, а потому, что проект автоматизации — крайне сложная штука.

20.12.2018 20:58:49

Thu, 20 Dec 2018 20:58:49 GMT

Полностью с вами согласен, кроме двух вещей: 1) Того, что ГОСТы устарели. Может, в чем-то и устарели, но ничего нового сопоставимого ни у нас, ни за рубежом не знаю. ИСО и IEEE со всех сторон так проект автоматизации не охватывают. 2) Того, что в ГОСТе нет шаблонов. Вот как раз этого там хватает. Приводится содержание около 60-и документов для разных стадий: выбирай не хочу. И фраза про общие слова «за все хорошее против всего плохого» относится не к ГОСТу, а к тем, кто пишет всякую ерунду, лишь бы разделы заполнить. Я как раз за то, чтобы воду исключать. ГОСТ позволяет делать с документами что хочешь, он очень гибкий. Это просто шаблон, а мы можем его использовать как хотим.

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

20.12.2018 17:07:58

Thu, 20 Dec 2018 17:07:58 GMT

Спасибо, обязательно изучу.

20.12.2018 10:03:14

Thu, 20 Dec 2018 10:03:14 GMT

Мне кажется, что вам просто «повезло» встретиться с людьми, использующими ГОСТ для галочки, а не для реальной работы. С Госуслугами, скорее всего, тоже так. Работаю много с госконтрактами: да, там всюду ГОСТ, и почти всюду в какой-то извращенной форме. К сожалению, в большинстве контор разработка и составление документов — абсолютно непересекающиеся процессы. Это не работа по ГОСТ, а мазохизм.

И ГОСТ 34 очень гибкий: добавляй, удаляй что хочешь, это прямо прописано. Голову-то никто не отменял. Смотришь один стандарт, смотришь другой, берешь оттуда нужное тебе, и вперед.

Ну и про то, что люди считаются персоналом, винтиками, в этом я с вами не согласен. Точенее, согласен, что так и есть, но не по ГОСТу, а в наших реалиях. Не вижу ничего плохого в том, чтобы определить количество необходимых нам людей, их квалификацию, продумать план их обучения. Или вечный бардак сделай то не знаю что лучше?

В общем, мне кажется, что кто-то вас сильно достал с ГОСТом, но этот кто-то, скорее всего, неправильно его применяет.

12.12.2018 07:22:24

Wed, 12 Dec 2018 07:22:24 GMT

А Ваша работа — нанятый консультант по предпроектному обследованию?

Да, бывало и такое. Одно дело, у заказчика уже есть хоть что-то вроде ТЗ, а другое — только идея: приходится им объяснять, что надо стачала заплатить за исследование, ТЗ, а потом разработку обсуждать. И таких много. Просто смотря в какой сфере работать: понятно, что с госами такого не будет, да и цели у них бывают другие…

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

12.12.2018 06:50:56

Wed, 12 Dec 2018 06:50:56 GMT

Спасибо большое за развернутый комментарий. Приятно, когда кто-то вчитывается и пытается применить прочитанное к себе. Отвечу на часть ваших комментариев:
1. Насчет вопроса о том, на чем зарабатывать: я много имел дело со стартапами, а там люди иногда реально не задумываются, из чего деньги получать будут. Они придумали классную идею и даже не понимают, что им потребуются постоянные расходы: хостинг, модерация и т.д. Поэтому, как ни странно, при первой же встрече с потенциальным заказчиком приходится задавать этот вопрос.

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

А вам уже не нужно доказывать важность исследования, для вас нужна другая статья. Хотя сегодня постараюсь добавить в эту статью список документов, которые желательно подготовить на предпроектных стадиях.

12.07.2018 19:30:59

Thu, 12 Jul 2018 19:30:59 GMT

Я боюсь, вас когда-нибудь сожгут на костре.
Кстати, вот если надо найти инвесторов, то действительно иногда следует сварганить что-нибудь по-быстрому, показать красивую картинку… а потом все переделать.

12.07.2018 19:20:46

Thu, 12 Jul 2018 19:20:46 GMT

Конечно, сложные системы разбиваются на подсистемы, каждая из которых может по своей методике разрабатываться и разными командами. Куда без модульности? И даже в рамках одной небольшой системы делишь все на функциональные блоки. В этом-то и состоит задача аналитиков и проектировщиков: разгрести кучу-малу требований и разбить их на блоки, очереди разработки и т.д.

12.07.2018 08:31:15

Thu, 12 Jul 2018 08:31:15 GMT

Ага, и еще: «Мы же это говорили уже тыщу раз». Вот поэтому составляю после каждого разговора протокол, где излагаются решения и задачи на исполнение. Потом тыкаю протоколами.

10.07.2018 10:07:01

Tue, 10 Jul 2018 10:07:01 GMT

Есть у меня такое странное ощущение, что ваши схемы годятся только для больниц, домов престарелых и других замшелых учреждений, которым надо «внедрять ИТ». А тем, кто с помощью компьютеров деньги зарабатывает, ваши схемы, как мёртвому припарка?

Если говорить про бизнес, то ведь сначала готовится пилот, MVP, а потом идут доработки. Базовую разработку лучше делать проектным методом. Мелкие и даже средние доработки — это всегда гибкие технологии, без вариантов, нечего там проектировать. Добавление каких-то крупных функциональных блоков лучше делать проектом, чтобы сначала все изучить, а потом кодить, иначе все посыпаться может.

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

В общем, один метод не отменяет другого. Надо уметь владеть и тем, и тем. К сожалению, среди «проповедников» Agile много людей, которые не владеют проектным методом, поэтому его и хают. Для освоения проектного метода требуется 10-20 лет по факту (ИМХО), надо не только изучить сам подход на 3-4 длительных проектах, но и знать несколько предметных бизнес-областей изнутри (продажи, маркетинг, производство, склад, транспорт, бухгалтерия и т.д.) Этому не научить в институте, не освоить на раз-два, это дается только опытом, на собственных многочисленных ошибках. Легче придумать, почему это не нужно (опять же ИМХО). Но гибкие методы нужны, без них никак! Только использовать их нужно по уму.

10.07.2018 08:21:06

Tue, 10 Jul 2018 08:21:06 GMT

Целиком поддерживаю! Вы читаете мои мысли, которые мне не удалось выразить в этой статье. Главное правило: не пользоваться тупо методиками, какими бы совершенными они ни были, а голову включать всегда и везде! И Один метод не исключает другого. Базовую функциональность спроектировали по вотерфолу, а замет поюзали, попробовали, поняли, что и где неудобно и чего не хватает: пошла гибкая разработка. А вот выбор, что есть базовое, с чем мы можем выйти на рынок, надо определять в каждом конкретном случае отдельно.

В общем, вам от меня респект и уважуха!

09.07.2018 16:13:02

Mon, 09 Jul 2018 16:13:02 GMT

По моему опыту, качественное ТЗ и техпроект экономят уйму времени, на разработку уходит в 2-3 раза меньше времени, т.к. разработчики кодят, а не гадают. И опять же, смотря что нужно. Если допилить пару фичей, то достаточно наброска, а не ТЗ. Если же у нас сотня объектов и сложная логика, то методом проб и ошибок 10 лет будешь двигаться. Да, первый результат покажешь очень быстро, а вот с конечным выйдет заминочка.

09.07.2018 16:09:22

Mon, 09 Jul 2018 16:09:22 GMT

Имхо, чем более творческий результат нужно получить, тем тяжелее на него написать ТЗ

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

А по поводу сложности написания ТЗ, все зависит от составителя. Для средней системы я обычно пишу за 2 недели, 2-3 недели согласовываю. Но здесь главное — заказчик рассказывает идею, а как она будет реализована, определяю я и согласовываю. Для этого надо понимать сам бизнес, как это должно быть реализовано. От заказчика ждать этого нецелесообразно. В этом-то собака и порылась. Ну и бывают заказчики-формалисты, особенно в госах.

09.07.2018 13:12:58

Mon, 09 Jul 2018 13:12:58 GMT

Вот для этого я и стараюсь сначала «продать» разработку ТЗ, а потом все уточняется. В процессе согласования ТЗ заказчик вовлекается в процесс и начинает понимать, что ему все-таки нужно и что это стоит. Это прием такой: вы типа риски снижаете, чуток платите, зато можете с ТЗ пойти куда угодно и получить оценку.

09.07.2018 13:10:23

Mon, 09 Jul 2018 13:10:23 GMT

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

09.07.2018 08:25:28

Mon, 09 Jul 2018 08:25:28 GMT

Agile не для ИТ, и не про ИТ. Agile для бизнеса и про бизнес.

Интересная мысль, можете пояснить?

09.07.2018 06:31:04

Mon, 09 Jul 2018 06:31:04 GMT

Опять же, все зависит от масштабов. Для строительства баньки на участке проект не нужен, а многоквартирный дом — другое дело. Разработать простое мобильное приложение с 5-ю экранами можно и путем проб и ошибок, но если у вас в системе нужно реализовать несколько десятков взаимосвязанных объектов и сложную логику, то методом «научного тыка» будет долго и дорого. И результат быстро будет не увидеть, как ни крути.