Перейти к основному содержимому

7. Проект - о разделе

О разделе​

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

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

Так, вас судьба привела к договору на оказание услуг по разработке информационной системы силами исполнителя. Этим исполнителем оказывается некая IT-компания, у которой всё чётко поставлено и организовано. И эта организация управления проектами в сфере информационных технологий является таким же специфичным для отрасли стилем, как и ведение проектов в строительстве, или финансовой сфере.

Общий поток всегда один:

Договоренность - Выполнение работ/оказание услуг - Сдача результата в срок.

И чтобы сдать результат в срок в строгом соответствии с условиями договора, нужно внутри организации-исполнителя грамотно поставить «конвейер» поставки продуктов. Для этого мы должны собрать команду, которая включает в себя руководителя проекта (с которого будем требовать), всех сопутствующих обслуживающих менеджеров и специалистов (эксперты, финансисты, бухгалтера, экономисты, юристы, маркетологи, администраторы, безопасники и прочие важные спецы), и самое главное - команду разработки.

В этой команде разработки мы должны включить несколько важных категорий:

  1. Архитектор системы. Он должен будет, по договорённости с руководством и с заказчиком-бизнесменом, обсудить единую общую картину, как всё должно работать в результате, и именно ему предстоит всё распределить, спроектировать, и подготовить итоговое крупное видение всех элементов системы. Он проектирует набор инструментов, языков, протоколов, способов интеграции, согласует коммуникации и тому подобное, абсолютно так же, как главный архитектор здания. Это, как можно понять, должен быть самый грамотный специалист, с большим опытом работы, ведь именно его ошибка будет стоить максимально дорого. Если ошибается архитектор в выборе технологии или подхода, вся система будет не соответствовать ожиданиям и это очень, очень плохо.
  2. Аналитики. Тут могут быть разные ребята - бизнес-аналитики, системные аналитики, аналитики данных, но они объединены единой целью - разобраться, и детализировать конкретные направления, которые решил архитектор. Ошибка аналитика является второй по приоритетности, так как он должен изучить логику, и если реализация будет хромать из-за него, придётся откатываться назад по целому направлению.
  3. Разработчики. Это «строители», которые будут строить по проекту и анализу, как по чертежам. Это глубокие технические специалисты, которые сами разберутся с кодом и низкоуровневыми проблемами, но при этом они не лезут в выбранные решения по технологиям и реализациям. Аналитиком сказано, что нужно сделать так - разработчик сделает именно так, как сказано, так как он не видит всей картины. Пример со строителями - они положат бетонные плиты и кирпичи именно там, где сказано в проекте, их обязанность - соблюдать точность, ведь они не знают всей задумки. Сказано на 5 сантиметров выше - значит делаем так. Если это плохое решение, отвечать будет тот, кто выставил требование. Ошибку разработчика можно исправить, попросить переделать, пофиксить баг, изменить код, переписать и улучшить. Так что она третья в приоритете.
  4. Тестировщики. Это те, кто проверит, точно ли в соответствии с требованиями реализована работа программы. Словом, точно ли там 5 сантиметров? По приоритетности ошибки тестировщика спорно. По идее, это четвертый приоритет, но всё же могут быть ситуации и критичные. С одной стороны, если ошибка допущена, и не замечена тестировщиком, то она всё равно есть, и выплывает позже рано или поздно, и её останется лишь исправить. Если это ошибка разработчика. Ошибку аналитика или архитектора тестировщик лишь выявит/не выявит, но природа ошибки, как её приоритет, сохранится за ответственными лицами. Поэтому ответственность тестировщика равнозначная любому проверяющему - если пропустить важный момент, то ошибка тестировщика лишь сохранит чужую ошибку. Можно сказать, что тестировщик это второй шанс, спасительная инстанция, которая может в перспективе защитить от убытков. Многие IT-компании (особенно в игровой индустрии) высший приоритет ставят именно тестированию, чтобы ничего не упустить.

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

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

Здесь сосредоточимся на команде, процессе и ответственности. В реальном мире заказчик не спросит, как мы написали код, нас спросят, решена ли задача.

Помните - вас нанимают не потому что вы умный или хороший, а потому что вы решаете проблему заказчика/работодателя.

Общее о бизнесе​

Команда и управление​

Методология и жизненный цикл ПО​

Аналитика​

Тестирование​

Проектирование и архитектура​

Проектирование и архитектура​

Проектирование​

Интеллектуальные права​

Техническое письмо​

Базы знаний и задачники​

Культура кода​

Легаси-код​

Освоение главы0%