Разработка… она как наркотик — систему пишут, пишут, ведь «прет» же. А потом, вдруг оказывается — «алименты» нужно платить. А любое изменение системы влечет гору ошибок. А ведь еще в начале прошлого века великий Курт Гёдель предвидел это и строго доказал, что даже в арифметике у нас не хватает ума, чтобы выразить все ее законы без противоречий. А в программировании и подавно — мы начнем наступать себе на ноги и запутываться. Что, в общем-то, и происходит: то ноутбук ночью включается и перезагружается, то мобильные приложения сыпят ошибками так, что они из кармана начинают выпадать и разбегаться, бранясь и попискивая, по полу.
А как вам модные нынче бета-версии всего и вся? Cкоро самолеты начнут выходить в альфа-бета версиях, похоже.
Но ведь можно же программировать без ошибок, чтобы душа радовалась и пиво попить с клиентом было не только приятно, но и безопасно!
В этом цикле публикаций на тему разных аспектов разработки ПО я постараюсь сформировать минималистичный набор ценностей и правил, которые, во-первых, помещаются в голове у среднего человека, а, во-вторых, обычно, позволяют… побеждать с наименьшими затратами и сроками. Сегодня откровенно поговорим о сборе требований к программной системе.
Театр, всюду театр. А ведь отрасль разработки программного обеспечения несомненно выиграет, если все участники процесса будут говорить правду, во-первых, себе, а, во-вторых — никто не будет поддерживать бессистемные эмоции и служение Ктулху вокруг.
За примерами далеко ходить не нужно — модели открытой разработки и их успешность (не обязательно некоммерческие) убедительно показывают:
а также максимально справедливые коммуникации, основанные на доверии и уважении друг ко другу — ведут программное решение, например, веб-сайт, к успеху.
Мир активно меняется. Горизонтальные коммуникации происходят со скоростью света и если мы не научимся использовать это новое оружие — точно проиграем. Но вначале немного оглянемся вокруг.
Все просто. Достаточно вспомнить школьный курс геометрии. Научное понимание мира, в котором мы живем, базируется на… вере в «непреложные истины» = аксиомы, например в то, что «параллельные прямые не пересекаются» или в количество простых чисел в диапазоне (хотя это, правда, теорема, но она, собака, работает, но никто не понимает почему).
Доказать аксиому — невозможно, остается только верить, что она работает всегда. А слетать к горизонту событий Черной Дыры и проверить — мы пока не можем. И объяснить, почему между фотонами взаимодействие передается гораздо быстрее скорости света, тоже.
Многочисленные научные теории используют аксиомы для логического вывода теорем и так далее и так рождаются толстые книжки с определенным сроком гарантии. В результате, и это уже не смешно, Великая теорема Ферма была доказана в девяностых так, что понять доказательство может только горстка избранных с отличным уровнем специального образования, способных перелопатить несколько десятков страниц убористого текста с формулами под микроскопом :-) Именно поэтому до сих продолжаются поиски «настоящего», простого и красивого доказательства.
Даже в, казалось бы, ну что может быть проще, арифметике, неоднократно принимались попытки привести аксиомы в порядок — но воз и ныне там…
Аналогично, языки программирования и технологии, на которых мы с вами создаем веб-сайты, мобильные приложения и информационные системы, по сути, также представляют собой набор аксиом или точек отсчета, в которые также нужно сначала «поверить» и на которых строится фундамент технологии, но доказать, что они верные — нельзя (хотя, иногда, все же можно: попробуйте написать веб-сайт на C++ и увидите, сколько потеряете времени и денег).
Например, в мире Java/C# и других авторитетных и солидных, современных, строго типизированных языках со статической типизацией нужно только один раз взять и «поверить», что мир состоит из психопатов, склонных к насилию и потери самоидентификации, и поэтому «набор аксиом» делает все, чтобы защитить разработчика не только от коллег, но и от него же самого (конечно, я шучу).
В результате получаются программные системы, которые создаются долго, из железа и бетона, которые затем покрываются сотнями автотестов, а в результате может оказаться, что к моменту окончания строительства бизнес-требования давно устарели, ядерное оружие запретили и бункер с 100-метровыми стенами — пойдет сразу в музей. Но нередко такое восприятие мира — работает хорошо, например в разработке узко-специализированных систем или там, где цена ошибки — очень высока (банки и т.п.).
В мире динамических языков со строгой/нестрогой типизацией (PHP, JavaScript, Python, Ruby) набор аксиом совершенно, от слова «совсем», другой:
В мире функциональных языков, типа Haskell/OCaml, требуется поверить в то, что:
В результате, вместо простых скриптов-костылей «сделал, проверил, решил и забыл» на рабочем месте начинается настоящая научная деятельность и поиски «функции Бога» — очень ведь интересно выразить веб-сайт… набором функций без переменных, вау!
Я, конечно, преувеличиваю, но нет дыма без огня. Хотя в некоторых задачах этот подход работает просто отлично и лучшего подхода не придумали.
В области управления проектами ситуация еще больше покрыта псевдонаучным мраком. А причина хорошо известна: очевидное, лежащее на поверхности, простое и лаконичное решение в лоб:
в реальности, почему-то, не работает :-)
Опытные участники проектных команд хорошо знают, что заказчик часто, банально, не знает, чего хочет, ибо переполнен эмоциями, а задачки по математики в школе — списывал, что привело со временем к частичному «атрофированию части мозга», отвечающей за логически непротиворечивое выражение своих мыслей. Имея перед собой поэтические опусы, рисунки губной помадой и записи гитарных аккордов, вместо технических требований к веб-сайту, специалисты, плача, чтобы не засмеяться от бессилия, увеличивают оценки объема работ на порядок, вводят налог за неадекватность и так далее.
В этих условиях отсутствия строгой логики и желания, простите, использовать голову по назначению, как на дрожжах, возникают страшные ненаучные злоупотребления в стиле астрологии/нумерологии/праноядения и гадания на кофейной гуще.
Злоупотребления, обычно, активно эксплуатируются очень уверенными в себе людьми, умеющими хорошо убеждать, которые никогда в руках «кода» не держали (да, я про неправильно приготовленный Agile).
Говорят, в некоторых командах перед спринтом даже, особо ярые поклонники, принуждают нас, инженеров, к, простите, уринотерапии :-) Однако сами эти «практики», нередко создаются очень опытными разработчиками, которые, как никто другой, могут ими правильно пользоваться.
Мне тут очень нравится аналогия с нунчаками — вроде нехитрое оружие, но вот правильно воспользоваться им могут единицы, а большинство получают травму, простите, сами знаете чего.
Иногда нас пытаются убедить во взаимозаменяемости инженеров. Известно, чтобы хорошо и глубоко разобраться в программной технологии, нужно перечитать немало книг, прослушать с десяток курсов, решить несколько сотен задачек и принять участие в пятерке программных проектов, из которых, минимум один, пришел к финишу. Дальше — начинается опыт, который лет через 5, как минимум, делает из кодера — Специалиста.
Обычно, постоянно работая над проектами, разработчик хорошо владеет одним-двум языками программирования и смежными технологиями. Успех и профессиональный рост инженера кроется именно в его узкой специализации, т.к. помимо самих языков необходимо глубоко копаться в системных библиотеках, которых, часто, очень много и документация к ним очень обширная.
Проблема в том, что сейчас, почему-то, модно книжки не читать — а гуглить и списывать, не включая мозг, параллельно ментально мастурбируя в социальных сетях и уведомлениях смартфона.
Найти настоящего специалиста, который системно учится снизу вверх, медленно, но верно, устраняя пробелы в собственных знаниях — становится все сложнее и сложнее. Рынок, к сожалению, наполнен «самоучками» с… «балованными ручками».
Во-первых, не нужно отчаиваться и очень важно не предаваться эмоциям. Необходимо четко понимать, что разработка — это, прежде всего, строгая математика (обычно на уровне школы) и логика с метриками, в которой нужно, используя тервер и интуицию, заниматься приоритетными рисками и «мочить» боссов еще в младенчестве.
Играли раньше в онлайн-игры и хорошо получалось — вот и продолжайте, только вместо боссов у вас будут программные проекты, а вместо багов — зерги!
Всегда можно и нужно трезво управлять рискам и, по опыту, если делать «системно и научно», программный проект либо взлетит в оговоренные сроки, либо быстро станет понятно, почему ракета не заводится и в чем/ком, конкретно, проблема.
С учетом вышесказанного рекомендуется как можно раньше начать придерживаться нижеперечисленных ценностей близко-научно-эмпирического подхода, которые тесно пересекаются с широко известным гимном здравому смыслу — "дзеном питона" и "agile-манифестом":
Узнав некоторые секреты и особенности тенденций в разработке программного обеспечения, уверенно двинемся дальше — научимся правильно собирать требования к системе.
Ничего смешного — вполне таки штатная ситуация. Да и заказчик в этом контексте — понятие собирательное. Прежде всего постарайтесь оценить уровень логического мышления и способности концентрироваться представителей клиента. С кем вы собираетесь работать и кто вам будет помогать? Возможные варианты:
Еще важный момент тут — выстроить как можно более доверительные отношения с клиентом, показать свою открытость и желание помочь заказчику ясно выразить свои мысли. Нередко помогает некий тренинг, на котором представителям заказчика объясняют, как работать со следующими инструментами сбора требований:
Тревожные сигналы, которые будут свидетельствовать о надвигающихся проблемах в сборе требований:
В перечисленных выше клинических случаях, опять таки, хорошо помогает разработка на базе готового коробочного/облачного решения с уже готовой документацией. Такой подход на порядки снизит риски внезапных изменений курса на 180 градусов. Но гарантий уже меньше.
В случае же адекватного подхода со стороны клиента, желания учиться и понимать вас, искреннего желания запустить проект в срок и развивать дальше, неплохо помогает одновременное использование нескольких технологических платформ. Проектировать уже не страшно — вы чувствуете, что ответственность за сбор требований клиент разделяет с вами на 100% и можно попытаться сделать ему хорошо. Вы — страхуете друг друга и вместе боретесь со сложностью:
Если 2-3 недели, в крайнем случае месяц-полтора, не проходит ощущение, что вы участвуете в спектакле «поболтаем с умными видом и потянем время и свалим все на кого-нибудь», дергайте стоп-кран, поджигайте поезд и громко кричите в рупор: «расходимся по домам, дети! представление окончено».
Если серьезно, собирайте встречу с менеджментом клиента и настаивайте на включении в проектную команду адекватных сотрудников, понимающих в деталях, как устроен бизнес и способных ответить на строго поставленные вопросы инженеров. Или увольняйтесь — иногда это самый правильный шаг: сохраните лицо и вырастете как специалист.
В результате, можно считать процесс сбора требований успешным и имеет смысл двигаться дальше, если, совместно с заказчиком, вы смогли подготовить в течении пары-тройки недель следующие артефакты:
Если вышеперечисленных артефактов за указанный период собрать не удалось, а имеются лишь закрывающие пятую точку бумажки типа расплывчатого ТЗ «губной помадой», сотрудничать аналитики друг с другом не собираются, экспертов в предметной области на стороне клиента не предвидится, проблемы замалчиваются и царит атмосфера показухи и «только хорошие новости» — собирайте вещи: взлететь скорее всего вам не дадут, исследование Луны откладывается не неопределенное время и вы попали в театральное представление «потянем время еще чуть чуть пока не разгонят».
Для достижения настоящего успеха очень, очень важно по-настоящему любить программные системы, отдаваться сбору требований и проектированию на полную катушку, желать ракетам скорейшего старта, пить пиво с заказчиком, доверять друг другу и постоянно повторять про себя слова Эдсгера Дейкстры: «простота — залог надежности»!
С Наступающим всех и искренне желаю удачи в реализации программных проектов.
А как вам модные нынче бета-версии всего и вся? Cкоро самолеты начнут выходить в альфа-бета версиях, похоже.
Но ведь можно же программировать без ошибок, чтобы душа радовалась и пиво попить с клиентом было не только приятно, но и безопасно!
В этом цикле публикаций на тему разных аспектов разработки ПО я постараюсь сформировать минималистичный набор ценностей и правил, которые, во-первых, помещаются в голове у среднего человека, а, во-вторых, обычно, позволяют… побеждать с наименьшими затратами и сроками. Сегодня откровенно поговорим о сборе требований к программной системе.
Театр, всюду театр. А ведь отрасль разработки программного обеспечения несомненно выиграет, если все участники процесса будут говорить правду, во-первых, себе, а, во-вторых — никто не будет поддерживать бессистемные эмоции и служение Ктулху вокруг.
За примерами далеко ходить не нужно — модели открытой разработки и их успешность (не обязательно некоммерческие) убедительно показывают:
- ясность, открытость, смелость
- обсуждение с сообществом и клиентом
- быстрое выявление и решение проблем
а также максимально справедливые коммуникации, основанные на доверии и уважении друг ко другу — ведут программное решение, например, веб-сайт, к успеху.
Мир активно меняется. Горизонтальные коммуникации происходят со скоростью света и если мы не научимся использовать это новое оружие — точно проиграем. Но вначале немного оглянемся вокруг.
Откуда же взялась «священные войны» в программировании?
Все просто. Достаточно вспомнить школьный курс геометрии. Научное понимание мира, в котором мы живем, базируется на… вере в «непреложные истины» = аксиомы, например в то, что «параллельные прямые не пересекаются» или в количество простых чисел в диапазоне (хотя это, правда, теорема, но она, собака, работает, но никто не понимает почему).
Доказать аксиому — невозможно, остается только верить, что она работает всегда. А слетать к горизонту событий Черной Дыры и проверить — мы пока не можем. И объяснить, почему между фотонами взаимодействие передается гораздо быстрее скорости света, тоже.
Многочисленные научные теории используют аксиомы для логического вывода теорем и так далее и так рождаются толстые книжки с определенным сроком гарантии. В результате, и это уже не смешно, Великая теорема Ферма была доказана в девяностых так, что понять доказательство может только горстка избранных с отличным уровнем специального образования, способных перелопатить несколько десятков страниц убористого текста с формулами под микроскопом :-) Именно поэтому до сих продолжаются поиски «настоящего», простого и красивого доказательства.
Даже в, казалось бы, ну что может быть проще, арифметике, неоднократно принимались попытки привести аксиомы в порядок — но воз и ныне там…
Аналогично, языки программирования и технологии, на которых мы с вами создаем веб-сайты, мобильные приложения и информационные системы, по сути, также представляют собой набор аксиом или точек отсчета, в которые также нужно сначала «поверить» и на которых строится фундамент технологии, но доказать, что они верные — нельзя (хотя, иногда, все же можно: попробуйте написать веб-сайт на C++ и увидите, сколько потеряете времени и денег).
Например, в мире Java/C# и других авторитетных и солидных, современных, строго типизированных языках со статической типизацией нужно только один раз взять и «поверить», что мир состоит из психопатов, склонных к насилию и потери самоидентификации, и поэтому «набор аксиом» делает все, чтобы защитить разработчика не только от коллег, но и от него же самого (конечно, я шучу).
В результате получаются программные системы, которые создаются долго, из железа и бетона, которые затем покрываются сотнями автотестов, а в результате может оказаться, что к моменту окончания строительства бизнес-требования давно устарели, ядерное оружие запретили и бункер с 100-метровыми стенами — пойдет сразу в музей. Но нередко такое восприятие мира — работает хорошо, например в разработке узко-специализированных систем или там, где цена ошибки — очень высока (банки и т.п.).
В мире динамических языков со строгой/нестрогой типизацией (PHP, JavaScript, Python, Ruby) набор аксиом совершенно, от слова «совсем», другой:
- нас окружают умные люди, которые пишут сразу правильно и аккуратно
- мания преследования (изменение типа переменной ниже по листингу, доступ к скрытым членам класса другим разработчиком со «злым» умыслом, обязательно впереди потребуется глубокий рефакторинг кода и т.п.) — заболевание, от которого нужно постараться побыстрее вылечиться
- железо дешевеет, поэтому компилировать программу нужно лишь кусочками и то, при необходимости
- чем больше кода, тем больше ошибок, поэтому код должен сразу хорошо читаться, быть ясным, кратким и сексуальным
В мире функциональных языков, типа Haskell/OCaml, требуется поверить в то, что:
- любую задачу можно выразить функцией
- переменные, циклы и мутабельность — ведет к ошибкам (это так на самом деле)
- программирование — для избранных и склонных к аналитическому мышлению
В результате, вместо простых скриптов-костылей «сделал, проверил, решил и забыл» на рабочем месте начинается настоящая научная деятельность и поиски «функции Бога» — очень ведь интересно выразить веб-сайт… набором функций без переменных, вау!
Я, конечно, преувеличиваю, но нет дыма без огня. Хотя в некоторых задачах этот подход работает просто отлично и лучшего подхода не придумали.
«Крестовые походы» в управлении программными проектами
В области управления проектами ситуация еще больше покрыта псевдонаучным мраком. А причина хорошо известна: очевидное, лежащее на поверхности, простое и лаконичное решение в лоб:
- понять, чего хочет клиент
- привлечь специалистов и оценить объем работ
- написать код
в реальности, почему-то, не работает :-)
Опытные участники проектных команд хорошо знают, что заказчик часто, банально, не знает, чего хочет, ибо переполнен эмоциями, а задачки по математики в школе — списывал, что привело со временем к частичному «атрофированию части мозга», отвечающей за логически непротиворечивое выражение своих мыслей. Имея перед собой поэтические опусы, рисунки губной помадой и записи гитарных аккордов, вместо технических требований к веб-сайту, специалисты, плача, чтобы не засмеяться от бессилия, увеличивают оценки объема работ на порядок, вводят налог за неадекватность и так далее.
В этих условиях отсутствия строгой логики и желания, простите, использовать голову по назначению, как на дрожжах, возникают страшные ненаучные злоупотребления в стиле астрологии/нумерологии/праноядения и гадания на кофейной гуще.
Злоупотребления, обычно, активно эксплуатируются очень уверенными в себе людьми, умеющими хорошо убеждать, которые никогда в руках «кода» не держали (да, я про неправильно приготовленный Agile).
Говорят, в некоторых командах перед спринтом даже, особо ярые поклонники, принуждают нас, инженеров, к, простите, уринотерапии :-) Однако сами эти «практики», нередко создаются очень опытными разработчиками, которые, как никто другой, могут ими правильно пользоваться.
Мне тут очень нравится аналогия с нунчаками — вроде нехитрое оружие, но вот правильно воспользоваться им могут единицы, а большинство получают травму, простите, сами знаете чего.
Еще один миф — взаимозаменяемость
Иногда нас пытаются убедить во взаимозаменяемости инженеров. Известно, чтобы хорошо и глубоко разобраться в программной технологии, нужно перечитать немало книг, прослушать с десяток курсов, решить несколько сотен задачек и принять участие в пятерке программных проектов, из которых, минимум один, пришел к финишу. Дальше — начинается опыт, который лет через 5, как минимум, делает из кодера — Специалиста.
Обычно, постоянно работая над проектами, разработчик хорошо владеет одним-двум языками программирования и смежными технологиями. Успех и профессиональный рост инженера кроется именно в его узкой специализации, т.к. помимо самих языков необходимо глубоко копаться в системных библиотеках, которых, часто, очень много и документация к ним очень обширная.
Проблема в том, что сейчас, почему-то, модно книжки не читать — а гуглить и списывать, не включая мозг, параллельно ментально мастурбируя в социальных сетях и уведомлениях смартфона.
Найти настоящего специалиста, который системно учится снизу вверх, медленно, но верно, устраняя пробелы в собственных знаниях — становится все сложнее и сложнее. Рынок, к сожалению, наполнен «самоучками» с… «балованными ручками».
Что же делать? Рекомендуемые ценности для выживания
Во-первых, не нужно отчаиваться и очень важно не предаваться эмоциям. Необходимо четко понимать, что разработка — это, прежде всего, строгая математика (обычно на уровне школы) и логика с метриками, в которой нужно, используя тервер и интуицию, заниматься приоритетными рисками и «мочить» боссов еще в младенчестве.
Играли раньше в онлайн-игры и хорошо получалось — вот и продолжайте, только вместо боссов у вас будут программные проекты, а вместо багов — зерги!
Всегда можно и нужно трезво управлять рискам и, по опыту, если делать «системно и научно», программный проект либо взлетит в оговоренные сроки, либо быстро станет понятно, почему ракета не заводится и в чем/ком, конкретно, проблема.
С учетом вышесказанного рекомендуется как можно раньше начать придерживаться нижеперечисленных ценностей близко-научно-эмпирического подхода, которые тесно пересекаются с широко известным гимном здравому смыслу — "дзеном питона" и "agile-манифестом":
- Искать самое простое и ясное решение
- Чем яснее, тем правильнее
- Стало сложно — значит где-то косяк и нужно продолжать дальше искать
- Высокоумие — от неуверенности или трудного детства
- Способности человеческого мозга — ограничены, особенно под действием гормонов, а в некоторые периоды даже слишком
- От алкоголя и курения — мы интенсивно тупеем
- Мы — склонны быстро забывать даже то, в чем хорошо разбирались и даже совсем недавно
- Стремиться к максимальной прозрачности и открытости
- Уважать друг друга
- Поощрять максимально быстрое всплытие и обсуждение проблем в как можно более широком кругу — идеально сразу во всеми
- Делать выводы и не наступать на грабли 3.14 раза подряд :-)
Рекомендации по сбору требований
Узнав некоторые секреты и особенности тенденций в разработке программного обеспечения, уверенно двинемся дальше — научимся правильно собирать требования к системе.
Способен ли заказчик — думать в принципе?
Ничего смешного — вполне таки штатная ситуация. Да и заказчик в этом контексте — понятие собирательное. Прежде всего постарайтесь оценить уровень логического мышления и способности концентрироваться представителей клиента. С кем вы собираетесь работать и кто вам будет помогать? Возможные варианты:
- Политическая тусовка. Нужно сделать, к примеру, веб-проект к дате потому-что кто-то чего-то хочет/обещал… Требования размыты, детали не знает никто, а кто знал — давно уволится. Проект пилила команда, которая ушла и понять, что они напилили — практически невозможно. На стенах — высохшие мозги от, возможно, суицида ведущего программиста. Код — плохой и хрупкий, пахнет так, что глаза режет. Часто в такой ситуации пытаются найти, простите, «сакральную жертву», на которую можно будет свалить следующие полгода и… начать искать новую. Ощущение страха, депресняка и подавления открытости процесса с примесью крови на губах. Вероятность вовремя сделать программное решение, правда небольшая, тут все таки имеется — если делать заново на готовом фреймворке с готовой документацией. Обычно только так и никак иначе.
- Вы общаетесь с представителями клиента и понимаете, что людям искренне трудно непротиворечиво/формально излагать собственные мысли, которые путаются после третьего предложения, повторяются и ходят по кругу. Через 15 минут диалога начинаются жалобы на головную боль. Слышится смех, атмосфера тусовки, селфи, жизнь удалась… Но желания, в целом, понятны и искренние — нужно просто чуточку помочь их оформить строго. Вероятность взлететь тут обычно повыше, чем в п.1, но опять таки, обычно помогает использование как можно более готового, коробочного решения с готовой документацией и типовыми сценариями.
- Клиент хорошо понимает, чего хочет и пытается логически непротиворечиво излагать собственные мысли и желания. В этом ему помогает аналитик, который не путается, излагая мысли менеджмента и выдавая их за свои. В команде клиента также есть минимум один эксперт в его предметной области (забавно, но это довольно таки редкая ситуация). В этом случае вероятность помочь и программно решить задачу — весьма высока. Тут можно ввязываться в проектирование, совместное обсуждение глоссария, модели объектов, модели данных, потоков данных, сценариев нагрузочного тестирования. Скорее всего собрать требования вы сможете и в разумные сроки.
Еще важный момент тут — выстроить как можно более доверительные отношения с клиентом, показать свою открытость и желание помочь заказчику ясно выразить свои мысли. Нередко помогает некий тренинг, на котором представителям заказчика объясняют, как работать со следующими инструментами сбора требований:
- Глоссарий, в котором записывают общие формулировки
- Логическая модель данных, в которой между элементами глоссария вводят строгие отношения множественности (один к одному, один ко многим, многие ко многим)
- Роли и цепочки использования, в которых показывают, кто пользуется системой и как
Тревожные сигналы, которые будут свидетельствовать о надвигающихся проблемах в сборе требований:
- представители заказчика переводят «стрелки» друг на друга и не могут двух слов связать, при этом очень много эмоций — тут рекомендуется как можно быстрее эскалировать проблему и выходить на уровень выше — иначе вас, как «сакральную жертву», принесут в дар культу бардака и выхода на пенсию/в декрет. Работать в таких условиях по Agile — крайне опасно, лучше писать строгое ТЗ и двигаться небольшими этапами
- представители клиента отвечают в стиле: ой, голова болит, а ты же умный, «программист», вот и разбирайся. Тут нужно требовать найти эксперта в предметной области, несущего ответственность за ответы от лица заказчика и как можно быстрее. Или см. пункт выше.
- о проблемах (нечитаемый код, отсутствие документации к основным бизнес-процессам) предпочитают не говорить, т.к. деньги были потрачены, должности получены, премии озвучены и проговаривание рисков может привести к интенсивной прочистке кадрового состава (все же все «понимают», а тут инженеры бочку катят) — тут сложно дать совет, действуйте по фактической погоде
В перечисленных выше клинических случаях, опять таки, хорошо помогает разработка на базе готового коробочного/облачного решения с уже готовой документацией. Такой подход на порядки снизит риски внезапных изменений курса на 180 градусов. Но гарантий уже меньше.
В случае же адекватного подхода со стороны клиента, желания учиться и понимать вас, искреннего желания запустить проект в срок и развивать дальше, неплохо помогает одновременное использование нескольких технологических платформ. Проектировать уже не страшно — вы чувствуете, что ответственность за сбор требований клиент разделяет с вами на 100% и можно попытаться сделать ему хорошо. Вы — страхуете друг друга и вместе боретесь со сложностью:
- веб-сайт на PHP с фреймворком, коробочным решением
- предиктивная аналитика на Python
- мобильное приложение либо на единой платформе, работающей везде, либо пишем под каждое устройство
Не тяните время!
Если 2-3 недели, в крайнем случае месяц-полтора, не проходит ощущение, что вы участвуете в спектакле «поболтаем с умными видом и потянем время и свалим все на кого-нибудь», дергайте стоп-кран, поджигайте поезд и громко кричите в рупор: «расходимся по домам, дети! представление окончено».
Если серьезно, собирайте встречу с менеджментом клиента и настаивайте на включении в проектную команду адекватных сотрудников, понимающих в деталях, как устроен бизнес и способных ответить на строго поставленные вопросы инженеров. Или увольняйтесь — иногда это самый правильный шаг: сохраните лицо и вырастете как специалист.
Чеклист
В результате, можно считать процесс сбора требований успешным и имеет смысл двигаться дальше, если, совместно с заказчиком, вы смогли подготовить в течении пары-тройки недель следующие артефакты:
- Глоссарий, в котором перечислены 50-150 терминов предметной области
- Логическая модель данных со связями терминов из глоссария
- Сценарии использования с терминами из глоссария
- Для сложных алгоритмов — блок-схемы или диаграммы активности UML
- Интерфейсы программной системы, логически не противоречащие вышеперечисленным пунктам
- Вы определились с набором аксиом, описывающих ваше отношение к миру = выбрали программную технологию. Тут многих, по причине любви к творчеству, тянет к садо-мазохизму и желанию заново изобрести велосипеды — боритесь с этим желанием. Определитесь: или весь мир полон подвохов и психопатов и делаем бункер, выдерживающий атаку НЛО, или разработчики искренне хотят вам помочь. Лучшая технология и набор аксиом: развитый фреймворк или готовое коробочное решение — риски не взлететь снизятся на порядки (по опыту, взлетает 95% и выше проектов)
- Вы пропустили программную систему через заказчика, себя, через свой мозг и нигде не осталось мутных мест или эмоциональной жижи. Если такие потенциально протухающие места имеются (а это, как правило, происходит всегда) — включите их в план управления рисками и озвучивайте на каждом проектном совещании. И ждите, что вас подставят и обязательно спросят, как же вы это пропустили
Если вышеперечисленных артефактов за указанный период собрать не удалось, а имеются лишь закрывающие пятую точку бумажки типа расплывчатого ТЗ «губной помадой», сотрудничать аналитики друг с другом не собираются, экспертов в предметной области на стороне клиента не предвидится, проблемы замалчиваются и царит атмосфера показухи и «только хорошие новости» — собирайте вещи: взлететь скорее всего вам не дадут, исследование Луны откладывается не неопределенное время и вы попали в театральное представление «потянем время еще чуть чуть пока не разгонят».
Для достижения настоящего успеха очень, очень важно по-настоящему любить программные системы, отдаваться сбору требований и проектированию на полную катушку, желать ракетам скорейшего старта, пить пиво с заказчиком, доверять друг другу и постоянно повторять про себя слова Эдсгера Дейкстры: «простота — залог надежности»!
С Наступающим всех и искренне желаю удачи в реализации программных проектов.
altrus
Так-то теоремы Геделя о «нашем уме» ничего не говорят, они о другом, но для рекламы 1С-Битрикса и вполне сгодятся.
AlexSerbul Автор
Ну так аксиомы арифметики до сих пор в порядок отчего не привели? Шарики за ролики заходят, не хватает нейронов :-)
altrus
А что не так с аксиомами арифметики? Расскажите, пожалуйста.
AlexSerbul Автор
habr.com/post/167475
altrus
И?..
Прочитал два раза, ища проблемы аксиоматики Пеано.
Если не считать авторского отсебячного постскриптума, все нормально вроде.
AlexSerbul Автор
Комменты :-)
altrus
Комменты создают Пеано проблемы?
Буду признателен, если вы кратко укажите все-таки квинтэссенцию комментов. Всё это читать и выискивать что-то неизвестное времени нет.
AlexSerbul Автор
Я понимаю так, что любая аксиоматика, в т.ч. PA, не может объяснить некоторые вещи (примеры в комментах) и требуется другая теория (другой набор аксиом) и так до бесконечности. Нет целостной картины, даже в арифметике, не говоря уже о математике (непаханное поле в дискретке и т.п.) и других науках. У нас мозгов не хватает, возможно пока, увидеть единый набор аксиом для всего и вся, о чем и говорит Гедель (косвенно).
altrus
Во-первых, вторая теорема Геделя о неполноте верна только для формальных логических систем первого порядка, частным случаем которой является арифметика Пеано. Переносить ее на другие системы и теории нельзя. Проводить интерпретации с нематематическими структурами и человеческим миром, как минимум, странно, а так-то, глупо.
Во-вторых, сделать из второй теоремы Геделя о неполноте вывод об ущербности человеческого мозга, это… скажу просто — не вижу логики в подобном выводе абсолютно.
В-третьих, кто вам сказал, что арифметика Пеано должна быть полной? Кому она это должна? Вам?
В-четвертых, каждую секунду каждая окружающая вас вещь, каждая пронзающая вас электромагнитная волна доказывает что у математики никакого кризиса нет.
Потому что математика — царица всех наук (с)
AlexSerbul Автор
Давайте без математики, чтобы было проще понять — возьмем физику. Единая теория поля… где она? Одни догадки же. Одни теории, разные, как в математике — целостности нет. Хотя хочется верить, что есть :-)
altrus
Извините, я привык рассуждать о том, в чем разбираюсь. Поля без меня.
Кстати, а земля круглая?
AlexSerbul Автор
Без обид :-) Еще один «косяк»: иррациональность фундаментальных констант — pi, e. Или уродливое доказательство Теоремы Ферма. Возможно, это говорит о неправильно выбранной нами точке отсчета — набора аксиом. Да, это личное мнение. Но давайте лучше о статье порассуждаем — мне удалось доходчиво донести мысль о выборе языка программирования, как считаете?
altrus
Вам не нравится иррациональность pi, e?
Вы похожи на Пифагора. Ему тоже не нравилась иррациональность pi. Очень по этому поводу переживал. Но в современной математике иррациональность этих величин, вроде, никакого негатива человечеству не несет.
По поводу статьи не могу ничего сказать. Так как как разработчик привязан к своим языкам, знаю когда какой применять, и встать на вашу — заказчика — сторону, чтобы оттуда сверху окинуть всю проблему взглядом, просто не могу.
fesst
Иррациональность — это фундаментальное свойство числа, оно не зависит от точки отсчёта.
AlexSerbul Автор
А это доказано, просто интересно, что не зависит от точки отчета? А трансцендентность?
fesst
Ну смотря что Вы называете точкой отсчёта. Иррациональность некоторых чисел — естественное положение дел.
Скажем, Вы решаете уравнение x^2 = a и привыкли, что у него два корня, когда справа — положительное число, являющееся точным квадратом (например, для a = 9, решения будут x1 = -3, x2= 3). Решая уравнение геометрически, используя теорему Пифагора, Вы обнаружите, что "решение" это длина гипотенузы прямоугольного треугольника со сторонами равными a (т.е., sqrt(a)). Если Вы возьмёте a = 2, и используете теорему Пифагора на прямоугольном треугольнике со стороной 1, вы быстры обнаружите, что гипотенуза должна быть "неопределённой в рациональных числах" длины sqrt(2). Предмет существования этого числа (при существовании единицы) после этого не должен быть вопросом, ведь Вы начертили отрезок гипотенузы, верно? Дальше Вы легко обнаружите, что sqrt(2) не может быть рациональным, ведь в рациональных числах x^2 = 2 не решается, о чём, как Вы ниже и написали, знали ещё древние греки. Скажите, где у меня в рассчётах точка отсчёта? Ведь длина стороны у нас переменная. Если же речь про аксиомы, то последние лишь указывают на то, что должно быть и так верно для Вашей модели (иначе и модель не применима, и мы говорим ни о чём)
Трансцендентные числа — pi и e туда входят. Это следующая ступень иррациональности — "не быть алгебраическим числом".
P.S. Вас, возможно, позабавит факт, что e^(i * pi) = -1, где i — мнимая единица, и эти числа покажутся Вам красивее, чем Вы раньше думали о них. (Я имею в виду Ваше "косяк")
AlexSerbul Автор
А где мы начертили, в каком базисе? Ортонормальном, двумерном. А в другом если. Например в машине опорных векторов в некоторых случаях переходят в искривленное многомерное пространство через kernel-trick (иногда бесконечномерное) — интересно там что будет. Не зря же и Лобачевский и Риман перетаскивали геометрию в миры, где сумма углов треугольника не равнялась 180 градусам. И, кстати, Риман то нашел как искать число простых чисел, поменяв точку отсчета — перешел к комплексным числам. Я просто не математик, могу ошибаться, ища аналогии, простите если что.
fesst
Вы путаете систему отсчёта для изучения свойств объекта и сами свойства объекта. Теорема Пифагора — про прямоугольный треугольник в Евклидовом пространстве, а не каком-то ещё. В пространстве без нужных свойств Вам придётся найти новые ассоциации между знакомыми натуральными числами и корнями уравнения (или поискать новое построение), но Вам и не обещал никто ничего для такого пространства (в этой дискуссии, уверяю, вся нужная математика уже построена и работает. И всегда работала). По сути Лобачевский не точку отсчёта поменял, а угол зрения и стал смотреть на другой объект. Многое в математике об обобщении (комплескные числа — не замена вещественным, а обобщение), можно назвать процесс обобщения индукцией. Другой класс действий — аналогия — направлен на то, чтобы искать «общие свойства» у разных видов объектов, или, наоборот, отличные свойства, как вот в Вашем же примере суммы углов треугольника в проективном пространстве. Лобачевский не «тащил геометрию в другие миры», он обобщил геометрию на другой класс объектов. Связь с обычной геометрией тоже найдена (но не стоит думать, что она появилась с открытием, связь всегда была и будет всегда). Я ни разу не встречал в математике такого, чтобы новое вычеркнуло старое, в отличии от физических или ещё каких-либо применений математических моделей. Математика этим и прекрасна, она вещь в себе и раз установив какой-то факт, он будет верным (да и был верным тоже :)) всегда. Оттого и проблем «кризиса математики» нет. В соседней физике, да, сколько угодно, эксперимент обогнал теорию и т.п. Математика — не про эксперимент.
AlexSerbul Автор
А как же вычислительная математика? Алгоритмы машинного обучения работают, бизнес зарабатывает деньги, а теоретического объяснения — практически нет. Открыли, по сути, ящик Пандоры. Как инициализировать нейросети правильно — незнаем, как обучать на малом числе примеров — незнаем. Есть ощущение, что вычислительная математика стала сурово обгонять теоретическую, которая стала, я возможно неправ, заранее прошу прощения, бусковать и запутываться во все усложняющихся доказательствах, которые мало кто уже может проверить и содержащих, часто, ошибки. Может в вычислительной математике будущее, ибо наших мыслительных возможностей не хватает?
fesst
При условии вычисления того же, что и раньше, результат будет тот же. Вся математика — теоретическая, вычислительная математика — её раздел, занимающийся вычислительными методами. Вы же падение стакана со стола физикой не называете? Вот и вычисление само по себе отдельно не математика.
Большинство математических доказательств понимает большое количество людей, которые занимаются темой, так что не стоит так сильно переживать, на мой взгляд. Какие-то доказательства заменят на доказательства попроще, какое-то упрощение придёт как аналогия из другого раздела и т.п. Вообще, некоторые вещи просто трудно сразу проверить, вот хорошая аналогия: код написанный разработчиком тоже не сразу из тестирования выходит. :)
Мне кажется, Вы просто привыкли к линейному ходу истории и своей жизни, а прогресс пока описывается другой функцией, вот у Вас и диссонанс, что всё выйдет из-под контроля скоро.
P.S. Как мозг устроен мы тоже не знаем, люди на работу придут, а что там происходит внутри — уууу, опасные кожаные мешки, — вот где ящик Пандоры! :)
AlexSerbul Автор
Это точно :-) Пока не покидает ощущение глобального строительства Вавилонской башни.
fesst
Мне кажется, скорее мы умрём от жары в куче мусора, чем от сумасшедших нейронных сетей.
AlexSerbul Автор
Вот, кстати, органичная красота и стройность математики и заставляет меня думать о ее связи с нашим сознанием (мышлением), несмотря на критерий Поппера, который связывает математику с религией
AlexSerbul Автор
Кто сказал? :-) Математика — это физика работы нашего мозга, нашего сознания. Если в ней такие фундаментальные проблемы, значит и в мозге тоже.
fesst
Математика это не то, что Вы написали, Вы сами придумали это определение?
AlexSerbul Автор
Дайте Ваше.
fesst
Вы вот в комменты отправляете людей на прямые вопросы, тут не ответили, так что я предложу Вам сходить за моим определением в соседний коммент ниже. :) Можно и просто сходить в Википедию, и убедиться словосочетание «физика мозга» там не встретить, меня то определение тоже больше Вашего радует. Вы сами придумали своё определение?
AlexSerbul Автор
Да, встречал определение, что мышление основано, ВОЗМОЖНО, на физическом носителе. А т.к. математика выражает наше сознание, являясь абстрактной умозрительной наукой, модели которой на удивление хорошо работают в реальном мире, то ВОЗМОЖНО секрет этого — в физическом носителе нашего сознания.
fesst
Я привык к определениям без слова «возможно» :) Но слово полезное, много вопросов снимает, спасибо :)
AlexSerbul Автор
А как же тервер, ЦПТ, хи-квадрат распределение? Там все возможно же :-) Вот кстати, в том же тервере, геометрическое определение вероятности… тоже аксиома, не доказывается, почему-то. Скакнули из дискретного мира лихо.
fesst
Ну зачем выдумывать несуществующие «аксиомы-определения»!:) То, что Вам кто-то не дал определения/вывода из аксиом и прочего не означает, что это не было сделано кем-то в научном труде. Откройте любой учебник, где есть понятие «непрерывная функция распределения» и изучите вопрос (если хотите, конечно). Если Вы также найдёте понятие меры, то сможете узнать, что вероятность — это функция (ну, почти, корректнее — мера), нежели число. Теория вероятности это весьма строгая наука, с крепкой основой из математического анализа. Случайность обычно есть только в задачах, в этих задачах Вы всегда делаете допущение, что Ваша модель вероятности (ваша функция) имеет смысл, а дальше идёт строгая математика с этой вероятностью (в грубом приближении, — функцией от событий). Т.е. какое именно событие произойдёт сказать нельзя, оно случайно. Но какова вероятность каждого возможного события — полностью детерминированная/вычислимая вещь, её Вы и определяете в начале и по ходу решения задачи. Например, когда решают задачу про вероятность выпадения чётного числа на кубике с 6 гранями, обычно подразумевается (если не сказано иное), что все числа равновероятны, т.е. вероятности всех элементарных событий даны прямо в задаче (1/6), остаётся посчитать вероятность составного события. А если в задаче такой кубик, а в жизни — кубик с одной тяжёлой гранью — Ваша модель с равномерным распределением останется верной, просто к такой ситуации будет неприменима. Т.е. вероятностные модели точны, неточны применения к реальности и результаты реальных экспериментов.
В статистике Вы наоборот, ищете вероятность (функцию распределения, нахождение одной будет эквивалентно нахождению другой) и находите её свойства с некоторыми доверительным интервалом (перефразируя: с некоторой вероятностью, Вы нашли не то, что искали). Но и там есть всегда начальные допущения, Вы не для любых данных можете проворачивать любые методы мат. статистики.
В общем, я к тому это всё, что, мне кажется, не стоит разбрасываться такими «ничего не доказано, тут может быть что угодно, вероятность же». В этой области математики слово «возможно» имеет более строгий смысл, чем в повседневности.
AlexSerbul Автор
Спасибо, очень емко познавательно. Хотя я терверу достаточно много времени отдал — он очень помогает в прикладных задачах по разработке. Да и статистика очень полезная часто вещь. Можете, если не затруднит, прокомментировать современную теорию категорий?
fesst
Нет, извините, в теории категорий я, к сожалению, профан :) Не добрался.
AlexSerbul Автор
Спасибо Вам большое за очень познавательные комментарии вчера, поставил себе в планчик почитать!
AlexSerbul Автор
Вот, нашел, про аксиоматику тервера. Вот взяли и ввели (Колмогоров, кстати) пачку аксиом :-) ru.wikipedia.org/wiki/%D0%90%D0%BA%D1%81%D0%B8%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B0_%D0%9A%D0%BE%D0%BB%D0%BC%D0%BE%D0%B3%D0%BE%D1%80%D0%BE%D0%B2%D0%B0
fesst
Ну вообще, опять же не с потолка, просто это определение для большего числа ситуаций, чем Вам обычно могло быть нужно на практике (я лишь предполагаю). Давайте рассмотрим на кубике:
Omega — множество элементарных событий, их 6, i-ое будет значит, что выпало число i (i из {1, 2, 3, 4, 5, 6}). назовём их w_i. F — множество неэлементарных событий, это подмножество множества всех подмножеств Omega, часто оно выбирается как просто множество всех подмножеств. Таким и для кубика выберем, в нём будет 2^6 элементов: одно {} (пустое), 6 одноэлементных {w_i} множеств, 15 двухэлементных {w_i, w_j} где i <> j, 20 трёхэлементых, 15 4-ёхэлементных, 6 пятиэлментных, и последнее — единственное — 6-ти элементное, равное всему Omega. А P — это мера, по сути функция, которая F сопоставляет число от 0 до 1. Когда Вы хотите узнать вероятность множества A из F, Вы просто складываете отдельные вероятности элементарных событий (элементов A) из A. Аксиомы в данном случае просто требуют, что бы P({w_i, w_j}) = P({w_i}) + P({w_j}) (i <> j) (вообще, сколько не будь элементов, это должна быть сумма всех вероятностей элементарных событий),
например,
P(«выпало чётное») = P(«выпало 2, 4 или 6») = P(«выпало 2») + P(«выпало 4») + P(«выпало 6»),
согласитесь, это разумное требование.
Для правильного кубика с равновероятным выпадением сторон, это нетрудно проверить.
Также есть два правила P(Omega) = 1, что значит, что какое-то событие да произойдёт и P({}(пустое)) = 0, что тоже логично, ведь, интуитивно, вероятность, что не выпало ничего после броска — нулевая. ;)
AlexSerbul Автор
Спасибо за интуитивное объяснение. Я вчера глянул теорию мер, там, конечно, нужно покопаться порядочно :-) Я себе проще объясняю, как в 19 веке — через отношение элементарных исходов благоприятствующих к общим. Немного комбинаторики и 500 задачек из учебника Вентцель и очень помогло в свое время.
altrus
fesst
Да, к «физике мозга» ближайшее будет:
Математику уж затем учить надо, что она ум в порядок приводит. (М.В. Ломоносов)
AlexSerbul Автор
А теперь вопрос — кто Писатель то? :-)
AlexSerbul Автор
Распечатал, положил рядом. Буду перечитывать. Очень красиво. Спасибо!
AlexSerbul Автор
Кризис в математике с этого и начался в начале прошлого века, что полезли в множества, встретили бесконечность и запутались все к черту :-)
fesst
Бесконечность в множествах встретили гораздо раньше, ещё Евклид писал о бесконечности множества простых чисел.
AlexSerbul Автор
Да, веселое было время. Верили в целые и рациональные числа и иррациональность тогда же примерно и доказали, возможно случайно.
fesst
А какое тогда время было в науке невесёлое?
Вы вот говорите о кризисе в математике, хотя никакого кризиса в общем-то нет, наука бурно развивается и множество гипотез находят опровержение или доказательства.
Например, тот факт, что существует утверждение, которое нельзя ни доказать ни опровергнуть ещё не означает, что кому-то может потребоваться подобную вещь объяснять. Представьте, что кто-то сказал грамматически верное предложение, но с незнакомыми словами, нужно ли определять его истинность, имеет ли это смысл? Есть и другие примеры «необъясненных» вещей, такие как существование множества, находящегося по мощности между счётными натуральными и вещественным континуумом. Тем не менее, это не стоит называть «проблемами аксиоматики», потому что на проблему (в смысле «противоречия», а не задачи) не указывает. Да и всегда найдётся что-то новое, построенное на старом.
Выше Вы просили дать своё определение математики,
моё кустарное определение: математика это наука о взаимоотношениях идеальных объектов, заданных аксиомами. Всегда на основе этих объектов можно построить другие объекты, индукцией или аналогией, для них можно найти альтернативную аксиоматику, дающую объекты изоморфные построенным. Всегда найдётся что-то неизученное/вновь открытое. Так что единого набора аксиом всего и вся Вы и не встретите никогда. Да и не нужно (хотя за Вас не отвечаю).
P.S. В рациональные и целые числа не надо верить, существует строгое построение, основанное на аксиоматике Пеано и факторизации множества пар целых чисел по отношению эквивалентности, связанному с основным свойством дроби.
AlexSerbul Автор
Спасибо, очень интересно. Я пытаюсь, возможно не совсем четко, показать аналогию блужданий и поиска базы аксиом в области программирования, как очень молодой дисциплины. Математику же очень люблю и глубоко уважаю.
fesst
Не всё требует/позволяет математической обёртки :)
Palich239
Если глубоко не погружаться в математику и все, что с ней было связано — статья зашла с точки зрения работы клиент/исполнитель (автор, ты набил немало шишек, судя по всему), на днях зачитаю коллегам — посмеемся… сквозь слезы...)) По существу: ждём в новой статье дополненный список ситуаций и рецептов (как у реаниматологов) уже из чего-то ещё опыта ;) Должно быть полезно сообществу разработчиков. Может и от себя в личку добавлю, если есть необходимость. За статью спасибо
AlexSerbul Автор
Как чисто прикладной инженер-разработчик, не математик ни разу, в масле и опилках с ключом в руках, я просто попытался найти в великой науке помощь и объяснение показанным в посте жутким примерам из жизни, да :-)