Почему в очередной раз откладывается Хардфорк?
И как мы можем помочь команде разработчиков в этой ситуации?
Картинка найдена на pixabay по слову "complexity" *
Вчера появилось объявление о том, что так долго ожидаемый Хардфорк в очередной раз откладывается. Подобные новости радости приносят мало и наверняка у многих людей, особенно непричастных к разработке ПО, возникает ощущение, что команда попросту поплевывает в потолок, проедая деньги инвесторов. С точки зрения нормального разработчика, оправдываться в такой ситуации — это довольно глупое и непродуктивное занятие, время и силы лучше всего потратить на работу над проектом или другие более интересные дела. Но с другой стороны, поддержка или по крайней мере понимание со стороны сообщества команде уж точно не помешают, для этого я собственно и пишу этот пост.
Первое, срыв сроков при разработке программ, в том числе и многократный — это абсолютно нормально. Нормально не в смысле хорошо, а в смысле — совершенно обычно, такая ситуация встречается настолько часто, что у людей хотя бы краешком знакомых с работой отрасли не вызывает никакого удивления. Наоборот, экзотической редкостью являются проекты, где все и всегда происходит точно по графику. Мне, например, за 15 лет работы о подобных проектах даже слышать не доводилось, не говоря уже о том, чтобы в такой чудной разработке поучаствовать лично.
В реальной жизни почти всегда приходится или отодвигать сроки или на ходу урезать функциональность продукта или делать и то и другое одновременно. Проблема эта известна уже достаточно давно, например, классическая работа на эту тему — книга Фредерика Брукса «Мифический человеко-месяц» была написана еще за три года до моего появления на свет и с тех пор, к сожалению, мало что изменилось.
Когда вы знакомитесь с программированием в школе или университете, решаемые задачки достаточно просты и, если немного напрячься, их вполне можно сделать за вполне определенное время. Из-за этого у людей часто возникает иллюзия, что процесс разработки так же предсказуем, как, скажем, сборка автомобилей на конвейере. Это действительно так, но только для очень простых или очень рутинных задач. Например, веб-студия может штамповать на потоке вебсайты-визитки за фиксированную плату и предсказуемое время.
Как только сложность проекта начинает расти, становится все труднее предугадать, сколько времени займет реализация нужной функциональности. А еще в оценке сроков выполнения задач, люди склонны к излишнему оптимизму. И чем сложнее задача, тем больше будет занижена оценка — это такая особенность человеческого мышления, присущая в том числе и профессионалам. Сделать тут мало что можно, существующие методики разработки ПО помогают держать это явление в определенных рамках, но не более.
Оптимизм при оценке времени выполнения, является одной из основных причин срыва сроков, ведь эти самые сроки обычно устанавливаются на основании оценки трудоемкости, данной разработчиками. Единственное, что в этом случае помогает, это отказ от больших релизов и переход на короткие итерации, когда продукт выпускается, например, каждые две недели. К сожалению, это возможно далеко не всегда. Например, скорее всего, не получится разделить на несколько итераций перенос большого числа связанных друг с другом изменений из одной крупной кодовой базы в другую.
Проблемы, описанные выше, будут возникать даже при работе в одиночку. При объединении разработчиков в команду, к ним добавляется множество других трудностей, что также не способствуют точному соблюдению сроков. Представьте, что за неделю до релиза, ваш коллега серьезно заболел, его работа осталась недоделанной, а без нее не работает функциональность, которую реализуют остальные разработчики. В простых случаях и при условии правильно организованного процесса разработки такая ситуация может быть разрулена без срыва сроков, просто всем остальным прийдется поработать сверхурочно. Но к сожалению, такое случается далеко не всегда, специализацию ведь никто не отменял. Если программист отвечал за кусок, завязанный на какой-нибудь сложной математике или использовании специфической библиотеки, другого выхода кроме переноса срока релиза может попросту не быть.
Еще стоит добавить, что управление разработкой ПО это отдельная область человеческой деятельности, такая же, как, например, медицина или архитектура. На эту тему написано огромное количество работ, для освоения этой специальности люди учатся и нарабатывают опыт десятилетиями.
Рассуждать об управлении процессом разработки без специальных знаний, опыта, а также без понимания особенностей конкретного проекта и команды, можно, но вот пользы, кроме вреда от этого скорее всего не будет. То же самое касается и различных «ценных» рекомендаций. Мало кому приходит в голову давать советы бригаде хирургов во время операции или группе инженеров, проектирующих мост, хотя работа этих специалистов также бывает небезупречной — пациенты время от времени умирают, а мосты изредка рушатся. Для конструктивной и полезной критики необходимы определенные, часто весьма специальные, знания и, естественно, опыт.
По-человечески вполне можно понять разочарование и возмущение пользователей, когда сроки внесения нужных для них изменений в очередной раз переносятся. Вот только выражение всех этих эмоций публично ничего хорошего не принесет. Члены команды Голос такие же люди, как и мы с вами, давление со стороны сообщества и всякие забавные идеи типа «давайте не дадим им зарплаты» уж точно не будут способствовать повышению производительности их работы, а вот помещать вполне могут.
Когда речь идет о технически сложной деятельности, то сделать что-то для людей, которые относятся к тебе по-человечески, а к твоим проблемам с пониманием, почему-то всегда получается гораздо легче и быстрее, чем для тех, кто пытается поставить под сомнение твой профессионализм, порулить процессом или еще каким-нибудь способом выкушать мозг чайной ложкой.
Вот как-то оно так. Выводы, надеюсь, каждый сделает сам, а мне остается лишь пожелать всем членам команды терпения и успеха в вашей нелегкой работе.