По факту получается следующее: на стратегическом уровне, уровне разработки базы и ключевых расчетных механизмов - обычная проектная технология а-ля ГОСТ34. А когда переходишь на стадию внедрения, то начинается куча мелких и не очень доработок уже по факту поступления запросов от пользователей или от членов команды, которые видят, что получается не то, что хотели.
Поверьте, за Яндекс.Карты - это очень сложный Инструмент: создать карты по спутниковым снимкам, склеить квадратики, начертить граф дорог, создать изображения для разных масштабов (генерализация), создать базу объектов и нанести их на карту. Это огромная работа. То есть Продукт - это только внешняя и очень малая часть Инструмента. Продукт без Инструмента работать не будет, даже Youtube.
Когда изучаешь новомодные технологии, надо понимать, что там очень мало нового (обычно вообще ничего) и очень много маркетинга. Ведь за любым брендом стоят лекции, вебинары, курсы, книги: и все это приносит хороший доход. Поэтому на Западе очень любят взять старую идею и выдать ее за что-то новое.
Насчет, является ли Agile новым подходом. На любом заводе был опытный цех, где работали фактически по Agile. Но готовые изделия уже по документации готовили. И еще: городской человеческой цивилизации как минимум несколько тысяч лет. Построено за эти века очень много: и пирамиды, и каналы, и корабли, и в космос летали. А это все — управление проектами. И только наивные могут полагать, что можно изобрести действительно новый метод управления
Насчет «легко и просто» — это можно сказать маркетинговый ход, чтобы заголовок привлекал. Конечно, составление ТЗ — тяжкий труд. Да и вообще разобраться в ГОСТ 34 сложно: не потому, что ГОСТ плохой, а потому, что проект автоматизации — крайне сложная штука.
Полностью с вами согласен, кроме двух вещей: 1) Того, что ГОСТы устарели. Может, в чем-то и устарели, но ничего нового сопоставимого ни у нас, ни за рубежом не знаю. ИСО и IEEE со всех сторон так проект автоматизации не охватывают. 2) Того, что в ГОСТе нет шаблонов. Вот как раз этого там хватает. Приводится содержание около 60-и документов для разных стадий: выбирай не хочу. И фраза про общие слова «за все хорошее против всего плохого» относится не к ГОСТу, а к тем, кто пишет всякую ерунду, лишь бы разделы заполнить. Я как раз за то, чтобы воду исключать. ГОСТ позволяет делать с документами что хочешь, он очень гибкий. Это просто шаблон, а мы можем его использовать как хотим.
Ну а про госзаказчиков (да и других) отдельная тема. Если нет понимания проекта автоматизации, того, что нужно попотеть самим, то никакие стандарты и самое лучшее ТЗ не помогут. Плохому танцору известно что мешает.
Мне кажется, что вам просто «повезло» встретиться с людьми, использующими ГОСТ для галочки, а не для реальной работы. С Госуслугами, скорее всего, тоже так. Работаю много с госконтрактами: да, там всюду ГОСТ, и почти всюду в какой-то извращенной форме. К сожалению, в большинстве контор разработка и составление документов — абсолютно непересекающиеся процессы. Это не работа по ГОСТ, а мазохизм.
И ГОСТ 34 очень гибкий: добавляй, удаляй что хочешь, это прямо прописано. Голову-то никто не отменял. Смотришь один стандарт, смотришь другой, берешь оттуда нужное тебе, и вперед.
Ну и про то, что люди считаются персоналом, винтиками, в этом я с вами не согласен. Точенее, согласен, что так и есть, но не по ГОСТу, а в наших реалиях. Не вижу ничего плохого в том, чтобы определить количество необходимых нам людей, их квалификацию, продумать план их обучения. Или вечный бардак сделай то не знаю что лучше?
В общем, мне кажется, что кто-то вас сильно достал с ГОСТом, но этот кто-то, скорее всего, неправильно его применяет.
А Ваша работа — нанятый консультант по предпроектному обследованию?
Да, бывало и такое. Одно дело, у заказчика уже есть хоть что-то вроде ТЗ, а другое — только идея: приходится им объяснять, что надо стачала заплатить за исследование, ТЗ, а потом разработку обсуждать. И таких много. Просто смотря в какой сфере работать: понятно, что с госами такого не будет, да и цели у них бывают другие…
Кстати, список документов вставил в конце статьи, перед заключением. Не уверен, что полный, но хоть что-то. Некоторые документы могут пересекаться: каждый сам должен выбирать для себя пакет.
Спасибо большое за развернутый комментарий. Приятно, когда кто-то вчитывается и пытается применить прочитанное к себе. Отвечу на часть ваших комментариев:
1. Насчет вопроса о том, на чем зарабатывать: я много имел дело со стартапами, а там люди иногда реально не задумываются, из чего деньги получать будут. Они придумали классную идею и даже не понимают, что им потребуются постоянные расходы: хостинг, модерация и т.д. Поэтому, как ни странно, при первой же встрече с потенциальным заказчиком приходится задавать этот вопрос.
2. По поводу того, что нужно привести пакет документов. Я ставил целью скорее побудить людей задуматься о том, что такое обследование вообще нужно. Ведь у нас сразу постановку программистам пишут, называя это ТЗ (кстати, на днях опубликую большую статью по составлению ТЗ — в Ворде 24 страницы), хотя даже идея еще не ясна.
А вам уже не нужно доказывать важность исследования, для вас нужна другая статья. Хотя сегодня постараюсь добавить в эту статью список документов, которые желательно подготовить на предпроектных стадиях.
Я боюсь, вас когда-нибудь сожгут на костре.
Кстати, вот если надо найти инвесторов, то действительно иногда следует сварганить что-нибудь по-быстрому, показать красивую картинку… а потом все переделать.
Конечно, сложные системы разбиваются на подсистемы, каждая из которых может по своей методике разрабатываться и разными командами. Куда без модульности? И даже в рамках одной небольшой системы делишь все на функциональные блоки. В этом-то и состоит задача аналитиков и проектировщиков: разгрести кучу-малу требований и разбить их на блоки, очереди разработки и т.д.
Ага, и еще: «Мы же это говорили уже тыщу раз». Вот поэтому составляю после каждого разговора протокол, где излагаются решения и задачи на исполнение. Потом тыкаю протоколами.
Есть у меня такое странное ощущение, что ваши схемы годятся только для больниц, домов престарелых и других замшелых учреждений, которым надо «внедрять ИТ». А тем, кто с помощью компьютеров деньги зарабатывает, ваши схемы, как мёртвому припарка?
Если говорить про бизнес, то ведь сначала готовится пилот, MVP, а потом идут доработки. Базовую разработку лучше делать проектным методом. Мелкие и даже средние доработки — это всегда гибкие технологии, без вариантов, нечего там проектировать. Добавление каких-то крупных функциональных блоков лучше делать проектом, чтобы сначала все изучить, а потом кодить, иначе все посыпаться может.
Если сравнить с разработкой «железа», то сначала самолет проектируют, затем создают один или несколько опытных образцов и по результатам их сборки, испытаний, «допиливают». Более того, бывает во время строительства корабля вносятся такие изменения, что приходится прорезать несколько палуб, чтобы заменить какой-то крупный агрегат, установленные в трюме.
В общем, один метод не отменяет другого. Надо уметь владеть и тем, и тем. К сожалению, среди «проповедников» Agile много людей, которые не владеют проектным методом, поэтому его и хают. Для освоения проектного метода требуется 10-20 лет по факту (ИМХО), надо не только изучить сам подход на 3-4 длительных проектах, но и знать несколько предметных бизнес-областей изнутри (продажи, маркетинг, производство, склад, транспорт, бухгалтерия и т.д.) Этому не научить в институте, не освоить на раз-два, это дается только опытом, на собственных многочисленных ошибках. Легче придумать, почему это не нужно (опять же ИМХО). Но гибкие методы нужны, без них никак! Только использовать их нужно по уму.
Целиком поддерживаю! Вы читаете мои мысли, которые мне не удалось выразить в этой статье. Главное правило: не пользоваться тупо методиками, какими бы совершенными они ни были, а голову включать всегда и везде! И Один метод не исключает другого. Базовую функциональность спроектировали по вотерфолу, а замет поюзали, попробовали, поняли, что и где неудобно и чего не хватает: пошла гибкая разработка. А вот выбор, что есть базовое, с чем мы можем выйти на рынок, надо определять в каждом конкретном случае отдельно.
По моему опыту, качественное ТЗ и техпроект экономят уйму времени, на разработку уходит в 2-3 раза меньше времени, т.к. разработчики кодят, а не гадают. И опять же, смотря что нужно. Если допилить пару фичей, то достаточно наброска, а не ТЗ. Если же у нас сотня объектов и сложная логика, то методом проб и ошибок 10 лет будешь двигаться. Да, первый результат покажешь очень быстро, а вот с конечным выйдет заминочка.
Имхо, чем более творческий результат нужно получить, тем тяжелее на него написать ТЗ
Для творческих результатов как раз гибкие методы более пригодны, когда ты двигаешься методом проб и ошибок.
А по поводу сложности написания ТЗ, все зависит от составителя. Для средней системы я обычно пишу за 2 недели, 2-3 недели согласовываю. Но здесь главное — заказчик рассказывает идею, а как она будет реализована, определяю я и согласовываю. Для этого надо понимать сам бизнес, как это должно быть реализовано. От заказчика ждать этого нецелесообразно. В этом-то собака и порылась. Ну и бывают заказчики-формалисты, особенно в госах.
Вот для этого я и стараюсь сначала «продать» разработку ТЗ, а потом все уточняется. В процессе согласования ТЗ заказчик вовлекается в процесс и начинает понимать, что ему все-таки нужно и что это стоит. Это прием такой: вы типа риски снижаете, чуток платите, зато можете с ТЗ пойти куда угодно и получить оценку.
Полностью согласен. Хочу уточнить. Во-первых, в рамках статьи и невозможно описать все. Ее цель — именно быть «вводной» и заставить людей задуматься. Правда, очень мало разработчиков видя смысл в тщательном проектировании. Во-вторых, и в вотерфоле требования меняются, без этого редко обходится. Но зато есть ТЗ, в котором все зафиксировано. Хочешь больше: пожалуйста допник. Хорошее ТЗ мне всегда очень помогает. И когда мы его с заказчиком согласовываем, заказчик уже погружается в проект и начинает формулировать нормально, что он хочет. Уже тем сам процесс составления ТЗ полезен. Вовлечь заказчика — дорогого стоит.
Опять же, все зависит от масштабов. Для строительства баньки на участке проект не нужен, а многоквартирный дом — другое дело. Разработать простое мобильное приложение с 5-ю экранами можно и путем проб и ошибок, но если у вас в системе нужно реализовать несколько десятков взаимосвязанных объектов и сложную логику, то методом «научного тыка» будет долго и дорого. И результат быстро будет не увидеть, как ни крути.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
По факту получается следующее: на стратегическом уровне, уровне разработки базы и ключевых расчетных механизмов - обычная проектная технология а-ля ГОСТ34. А когда переходишь на стадию внедрения, то начинается куча мелких и не очень доработок уже по факту поступления запросов от пользователей или от членов команды, которые видят, что получается не то, что хотели.
Поверьте, за Яндекс.Карты - это очень сложный Инструмент: создать карты по спутниковым снимкам, склеить квадратики, начертить граф дорог, создать изображения для разных масштабов (генерализация), создать базу объектов и нанести их на карту. Это огромная работа. То есть Продукт - это только внешняя и очень малая часть Инструмента. Продукт без Инструмента работать не будет, даже Youtube.
Насчет, является ли Agile новым подходом. На любом заводе был опытный цех, где работали фактически по Agile. Но готовые изделия уже по документации готовили. И еще: городской человеческой цивилизации как минимум несколько тысяч лет. Построено за эти века очень много: и пирамиды, и каналы, и корабли, и в космос летали. А это все — управление проектами. И только наивные могут полагать, что можно изобрести действительно новый метод управления
Ну а про госзаказчиков (да и других) отдельная тема. Если нет понимания проекта автоматизации, того, что нужно попотеть самим, то никакие стандарты и самое лучшее ТЗ не помогут. Плохому танцору известно что мешает.
И ГОСТ 34 очень гибкий: добавляй, удаляй что хочешь, это прямо прописано. Голову-то никто не отменял. Смотришь один стандарт, смотришь другой, берешь оттуда нужное тебе, и вперед.
Ну и про то, что люди считаются персоналом, винтиками, в этом я с вами не согласен. Точенее, согласен, что так и есть, но не по ГОСТу, а в наших реалиях. Не вижу ничего плохого в том, чтобы определить количество необходимых нам людей, их квалификацию, продумать план их обучения. Или вечный бардак сделай то не знаю что лучше?
В общем, мне кажется, что кто-то вас сильно достал с ГОСТом, но этот кто-то, скорее всего, неправильно его применяет.
Да, бывало и такое. Одно дело, у заказчика уже есть хоть что-то вроде ТЗ, а другое — только идея: приходится им объяснять, что надо стачала заплатить за исследование, ТЗ, а потом разработку обсуждать. И таких много. Просто смотря в какой сфере работать: понятно, что с госами такого не будет, да и цели у них бывают другие…
Кстати, список документов вставил в конце статьи, перед заключением. Не уверен, что полный, но хоть что-то. Некоторые документы могут пересекаться: каждый сам должен выбирать для себя пакет.
1. Насчет вопроса о том, на чем зарабатывать: я много имел дело со стартапами, а там люди иногда реально не задумываются, из чего деньги получать будут. Они придумали классную идею и даже не понимают, что им потребуются постоянные расходы: хостинг, модерация и т.д. Поэтому, как ни странно, при первой же встрече с потенциальным заказчиком приходится задавать этот вопрос.
2. По поводу того, что нужно привести пакет документов. Я ставил целью скорее побудить людей задуматься о том, что такое обследование вообще нужно. Ведь у нас сразу постановку программистам пишут, называя это ТЗ (кстати, на днях опубликую большую статью по составлению ТЗ — в Ворде 24 страницы), хотя даже идея еще не ясна.
А вам уже не нужно доказывать важность исследования, для вас нужна другая статья. Хотя сегодня постараюсь добавить в эту статью список документов, которые желательно подготовить на предпроектных стадиях.
Кстати, вот если надо найти инвесторов, то действительно иногда следует сварганить что-нибудь по-быстрому, показать красивую картинку… а потом все переделать.
Если говорить про бизнес, то ведь сначала готовится пилот, MVP, а потом идут доработки. Базовую разработку лучше делать проектным методом. Мелкие и даже средние доработки — это всегда гибкие технологии, без вариантов, нечего там проектировать. Добавление каких-то крупных функциональных блоков лучше делать проектом, чтобы сначала все изучить, а потом кодить, иначе все посыпаться может.
Если сравнить с разработкой «железа», то сначала самолет проектируют, затем создают один или несколько опытных образцов и по результатам их сборки, испытаний, «допиливают». Более того, бывает во время строительства корабля вносятся такие изменения, что приходится прорезать несколько палуб, чтобы заменить какой-то крупный агрегат, установленные в трюме.
В общем, один метод не отменяет другого. Надо уметь владеть и тем, и тем. К сожалению, среди «проповедников» Agile много людей, которые не владеют проектным методом, поэтому его и хают. Для освоения проектного метода требуется 10-20 лет по факту (ИМХО), надо не только изучить сам подход на 3-4 длительных проектах, но и знать несколько предметных бизнес-областей изнутри (продажи, маркетинг, производство, склад, транспорт, бухгалтерия и т.д.) Этому не научить в институте, не освоить на раз-два, это дается только опытом, на собственных многочисленных ошибках. Легче придумать, почему это не нужно (опять же ИМХО). Но гибкие методы нужны, без них никак! Только использовать их нужно по уму.
В общем, вам от меня респект и уважуха!
Для творческих результатов как раз гибкие методы более пригодны, когда ты двигаешься методом проб и ошибок.
А по поводу сложности написания ТЗ, все зависит от составителя. Для средней системы я обычно пишу за 2 недели, 2-3 недели согласовываю. Но здесь главное — заказчик рассказывает идею, а как она будет реализована, определяю я и согласовываю. Для этого надо понимать сам бизнес, как это должно быть реализовано. От заказчика ждать этого нецелесообразно. В этом-то собака и порылась. Ну и бывают заказчики-формалисты, особенно в госах.
Интересная мысль, можете пояснить?