Add lecture about finances

bachelor-3/semester-6/software-technology/main.tex

@@ -0,0 +1,248 @@
+\documentclass[12pt, a4paper, oneside]{memoir}
+%%% PDF settings
+\pdfvariable minorversion 7 % Set PDF version to 1.7.
+
+%%% Fonts and language setup.
+\usepackage{polyglossia}
+% Setup fonts.
+\usepackage{fontspec}
+\setmainfont{CMU Serif}
+\setsansfont{CMU Sans Serif}
+\setmonofont{CMU Typewriter Text}
+
+\usepackage{microtype} % Add fancy-schmancy font tricks.
+
+\usepackage{xcolor} % Add colors support.
+
+%% Math
+\usepackage{amsmath, amsfonts, amssymb, amsthm, mathtools} % Advanced math tools.
+\usepackage{unicode-math} % Allow TTF and OTF fonts in math and allow direct typing unicode math characters.
+\unimathsetup{
+    warnings-off={
+            mathtools-colon,
+            mathtools-overbracket
+        }
+}
+\setmathfont{Latin Modern Math} % default
+\setmathfont[range={\setminus,\varnothing,\smashtimes}]{Asana Math}
+
+%%% Images
+\usepackage{graphicx}
+\graphicspath{{figures/}}
+\usepackage{import}
+
+%%% Polyglossia setup after (nearly) everything as described in documentation.
+\setdefaultlanguage{russian}
+\setotherlanguage{english}
+
+\usepackage{csquotes}
+
+%%% Custom commands
+\AtBeginDocument{\renewcommand{\leq}{\leqslant}}
+\AtBeginDocument{\renewcommand{\geq}{\geqslant}}
+
+%%% HyperRef
+\usepackage{hyperref}
+
+\title{Денежная сторона IT проекта}
+\author{Кириленко Я.~А.\thanks{Конспект Пономарев Н.~А.}}
+\date{28 мая 2024 г.}
+
+\begin{document}
+
+\maketitle
+
+\section*{Введение}
+ЮВЛ просил рассказать по деньгам в проекте, но ЯА знает только как их тратить, так что будет рассказ о том как пролететь.
+
+Проекты~--- это некоторая осмысленная деятельность, ведущая к какой-то цели, в рамках ограниченных ресурсов.
+
+\enquote{Ваш труд нужен, только если он кому-то нужен!}
+
+Нам надо выполнить что-то и получить денег.
+Как получить денег?
+Надо понять наши потребности.
+Наша задача выполнить требования, а точнее вопрос управления ожиданиями ($\neq$ то, что задокументировано).
+Платят, потому что пользователь рад!
+Так что будем смотреть на все эти вещи сугубо с экономической стороны.
+Ценность вашей работы~--- ценность для потребителя.
+
+Сколько труда уйдёт на удовлетворения требований?
+Для этого служат методологии разработки, ибо цена разработки огромна, а требования не всегда отражают ожидания.
+
+К вам пришли и заказали простую и понятную вещь.
+Пришел Кириленко и говорит: \enquote{сделай мне калькулятор, но надо завтра!}.
+Сказал \enquote{нет}~--- Кириленко к врагам.
+Надо вселять уверенность, что ты на стороне заказчика.
+Вот это все будем сегодня говорить
+
+\section*{Оценка проектов}
+
+Справимся или нет~--- грубая оценка.
+Сказать готовы или не готовы.
+Не предполагает обширного диалога.
+Чувствуются высокие риски.
+
+ТКП (Технико-коммерческое предложение)~--- уже сильно более подробная штука.
+Это пойдёт в основу договора.
+
+Круто, но вообще надо уметь оценивать и по ходу проекта, ибо всё может пойти не так.
+
+...
+
+Бывает переоценка проекта.
+
+Надо различать оценку, бизнес-цель и обязательство.
+
+Оценка вообще имеет вероятностную природу.
+Простое правило: если можем измерять~--- измеряем, если не может~--- придумываем как.
+
+Программное управление~--- как запрограмировали так и идёт, т.е. косяков не бывает и всё работает как предсказано.
+Но это детская мечта, в жизни так не бывает!
+ВСЕГДА нужна обратная связь.
+(Это вообще про кибернетику)
+Поэтому всегда надо измерять, чтобы управлять.
+
+Зачем нужны всякие диаграммы Гантта?
+Хорошо планируем оптимальную траекторию, но вообще происходит всё что угодно.
+А проект надо завершать по срокам.
+
+Самый простой способ измерения объема проекта~--- SLOC.
+Но очевидно, что у него слишком много подковырок, хотя метрика достаточно приемлемая.
+
+Есть ли связь количества строк и количества фич?
+Удивительно, но есть!
+Особенно хорошо работает для крупных областей, например в сайтостроении.
+С большими фреймворками вообще бывает линейное соответствие.
+
+UCP~--- как-то распределяем попугаев по элементам программы.
+FP и всякое остальное: ссылки будут потом.
+Эти штуки с одной стороны ресерч, с другой стороны хороши, когда одинаковые проекты клепаются пачками.
+
+(Определения всех трёх смотри на слайде)
+
+Когда надо выполнить оценку, надо сделать \textit{объективную} оценку трудозатрат.
+Но обычно есть какая-то цепочка, которая говорит \enquote{надо сделать}.
+
+Оценка  в попугаях $\implies$ SLOC $\implies$ ещё более крутые метрики, но в конце проекта~--- печаль.
+
+Бизнес-цель, что от нас ждут (субъективна).
+Обязательства, на что договорились.
+
+Обязательства можно обсуждать, но потом должны стараться их выполнить как можно круче.
+
+В оценке не должно быть \enquote{кажется}.
+Правильно \enquote{Займет от ... до ..., вероятно столько-то}.
+
+Информации в начале сильно меньше, и она регулярно увеличивается в количеств.
+Есть ресерч старый всё ещё неплохо подходит, потому что совпадает с современным жизненным опытом (пока что верим религиозно).
+При первичной оценке может быть расхождения вплоть до четырёх раз в любую сторону.
+На моменте подписания договора уже до двух раз.
+Около 20\% будут где-то на моменте готового дизайна приложения.
+Расхождения будут нулевые, только когда (почти) закончим проект.
+Поэтому нужна регулярная переоценка.
+(Есть ещё числа от NASA, смотри слайд)
+
+\section*{Калибровка}
+
+Чтобы делать более точную оценку, нужны прошлые данные, лучше всего личные.
+В НИРах такого не бывает!
+
+Данные индустрии~--- хорошо, что есть, но слабо натягивается на собственные проекты.
+
+\section*{Ограничения}
+
+А что вообще влияет на оценку?
+Почему 3 попугая из скрама~--- это неделя одного разработчика?
+Житейский опыт определенной команды.
+
+Влияющие факторы, смотри на слайде.
+Какое-то исследование, выводы:
+если с заказчиком беседовал придурок, то есть шанс сделать проект в 1.5 раза быстрее или в 2 раза медленнее.
+Нужно очень хорошо знать команду.
+Если вы не компетентны, то прежде чем ввязываться в бизнес, надо сильно прокачаться, иначе будет больно.
+Для этого есть модель с супер формулой COCOMOII (с нелинейной зависимостью).
+
+Но обычно работает экспертный метод~(\enquote{Я считаю...}).
+Формально это не так, поэтому надо разобраться.
+
+\section*{Этапы процесса оценки}
+
+Желательно не одному, при этом люди должны быть с разными ролями, так как про чужие задачи никто не помнит.
+Больше инфы~--- меньше риски.
+Всегда можно позвать даже внешнего человека.
+
+Любая методика и инструментарий~--- результат взвешенного выбора командой, который нужно документировать.
+
+А что нужно будет сделать надо декомпозировать, это позволит найти похожие задачи в прошлом для лучше оценки.
+
+Дальше понятно, но что мы оцениваем???
+Это обсудим дальше.
+
+\section*{Сбор и анализ информации}
+Смотри жирное на слайде, остальное уже было.
+
+Заключить договор~--- взять обязательства.
+Наша задача быстро сужать конус, тем самым повышая точность.
+
+На каждом этапе есть понимание в виде допущений и открытых вопросов, НО документировано!
+Профессионализм аналитика/архитектора~--- предугадать граничные случаи.
+Всё, что не было записано, сыграет против вас.
+Условно \enquote{Мы имеем право выбрать фреймворк}.
+В идеале открытые вопросы обсуждаются и переходят в допущения, который понятны заказчику.
+
+Декомпозиция нужна~--- WBS основа (узнай сам).
+
+Модель оценки желательно формально описанный (с формулами) подход к проекту.
+(COCOMOII~--- монстр, а вот Scrum норм).
+
+\section*{Выполнение оценки}
+См. слайд
+
+Не бывает просто оценки.
+
+Всегда есть какой-то размер системы.
+
+Оценка трудозатрат.
+Сколько, что и как, но не размер системы.
+
+Длительность тоже понятно.
+
+Стоимость~--- как бы следует, но куча нюансов.
+Сложно загрузить на 100\%, поэтому платить как бы надо.
+Поэтому стоимость включает операционные расходы и внезапные риски.
+
+\section*{Риски}
+Про управления рисками и лирическое отступление можно почитать на слайде.
+(вообще было же)
+Риски все должны быть на заказчике, то есть он о них знает, а значит обговорены и (в идеале) вложены в стоимость.
+На слайде чеклист контролируете вы или нет, но это уже скорее для взрослого менеджера, а не третьекурсника.
+
+Что делать с рисками?
+
+Их можно заложить в стоимость, но если загнать все риски, то цена будет запредельной, что на текущем рынке равносильно смерти.
+Поэтому вместо этого планируем буфер. (см слайд)
+
+Риск общения с заказчиком: я ему сказал, он не понял $\implies$ коэффициент цены 1.1.
+
+Недооценить~--- ужасно.
+Переоценить можно, но делать будете всё равно всё доступное время и за все возможные деньги.
+Найти идеальную оценку сложно, но делает вас крутыми.
+
+Пока предупреждение: разработчики склонны забывать по 30\% задач.
+А по опыту ЯА, а ещё про 50\% задач не знают.
+Поэтому читай чеклист типичных пропущенные требования.
+
+... тут я выпал
+
+Теперь про стоимость ещё.
+Написать код~--- только часть расходов.
+В смету нужно записать риски, операционные расходы, налоги, зарплаты сотрудников, прибыль собственника.
+
+Всё хочется в договор, ещё и на год сразу.
+Выглядит сложно.
+Как решаем?
+Не работает Fixed Price, Time \& Material чуть лучше, поэтому договор по этапам.
+Сделали этап, договорились заново, примерно раз в 3-6 месяцев
+
+\end{document}