Хочу несколько преобразовать свой блог, открыв несколько постоянных рубрик. В рамках первой рубрики “Покер и Бизнес” буду писать о разных интересных ситуациях, с которыми мы сталкиваемся в ходе работы над бэкинговой биржей MTTmarket.com. Параллельно буду продолжать рубрику «Стратегии покерного игрока».

Собственно, пару слов о целях данного цикла текстов. 

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

Во-вторых, мне интересно сформулировать какие-то вещи для себя самого. Знать и понимать – это одно, прописать и проговорить – это другое.

Во-третьих, в проекте MTTmarket есть помимо меня другие сотрудники, и мне проще один раз написать текст, чем рассказывать каждому голосом.

В-четвертых, данная рубрика позволит мне немного рассказать о том, как разрабатывается и развивается проект MTTmarket, и как он выглядит изнутри. Это позволит сделать его более открытым и человечным.

Процесс разработки программного продукта

Есть достаточно много способов погубить любое хорошее дело, при этом действуя в строгом соответствии с добрыми намерениями и желанием все сделать хорошо и довести до конца. Соответственно, я буду говорить не про лень или какие-то очевидные ошибки, а про неверно выбранные методологии деятельности.

Здесь и далее я буду говорить в большей степени о бизнесе, в особенности о разработке интернет-проектов, но большинство размышлений может быть отнесено и к другим областям деятельности человека.

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

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

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

Ошибки расстановки приоритетов задач разработки

Ошибка 1: Избыточный функционал

Очень часто в IT-разработке возникает желание то тут, то там дописать какую-то дополнительную приятную штуку, которая будет всем радовать глаз, но… никак не облегчит жизнь пользователю, и не принесет дeньги проекту. Или облегчит и принесет, но на дистанции издержки появление дополнительной сложности выведут данное действие в минус.

Ошибка 2: Микроулучшения

Ошибка – ближайший родственник предыдущей. Суть стратегии микроулучшений состоит в том, что IT-предприниматель под давлением среды, клиентов, своих собственных представлений о прекрасном, а порой и просто по инерции, вкладывает большую часть временных и финансовых ресурсов в небольшие улучшения своего продукта (как правило – не профильных его частей). Ведь всегда можно что-то подшлифовать и улучшить.

Ошибка 3: Сделаю все сам!

Например, мы развиваем какой-то проект А, и понимаем, что нашим пользователям был бы крайне полезен функционал, который есть у проекта Б, при этом проект Б не обладает нашим функционалом. В большинстве случаев правильным решением будет интегрироваться с проектом Б, но на практике в большинстве случае происходит следующее: «проект Б – говно, мы сделаем лучше».

Ошибка 4: Не дадим пользователю ошибиться!

С одной стороны, руководитель IT-проекта всегда должен cтремиться к тому, чтобы пользователь не мог допустить ошибку (то есть чтобы результат действий пользователя соответствовал его ожиданиям), с другой – избыточное стремление обезопасить пользователя от глупости приводит к решению задач, покрывающих 0,001% действий пользователей, но при этом отъедающих большие ресурсы.

Ошибка 5: Срочное исправление всех ошибок

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

Ошибка 6: Отсутствие внимания к „невидимой" части: комментирование кода, внутренние тесты, документация.

При правильной методологии разработки трудозатраты на написание функционала сопоставимы с затратами на „обслуживание” кода: комментирование кода, написание технической документации, написание внутренних автоматических тестов и.т.д. Попытка бежать вперед паровоза и бросать все силы на написание нового рано или поздно приводит к тому, что рано или поздно система сыпется.

На следующей неделе поговорим об этих ошибках подробнее, с примерами из практики http://MTTmarket.com и других проектов.