Опасайтесь обобщений

в 6:37, , рубрики: здравый смысл, методологии, разработка, управление проектами, метки: ,

Существует много модных современных концепций: Agile, Lean Startup, Customer Development, Worse is Better, TDD, SaaS. Все они хороши. Вникание, а тем более использование, сильно расширяет горизонты. Но надо понимать, что это всё довольно общие вещи. Нужно не забывать использовать голову и чётко осознавать применимость в собственном проекте.

Фанатичное следование методологии напоминает восторг от осознания какой-то возможности в языке программирования. Я сам поддавался такому не раз: «Круто, в Python есть метаклассы — срочно используем в проекте» — несмотря на то, что того же самого можно было добиться обычными атрибутами класса. «Вау, макросы Lisp — это супер, накодим их побольше» — хотя можно было обойтись функциями высшего порядка. Сначала делаешь так, а со временем свыкаешься и уже не суёшь эту мощную возможность куда попало, а используешь, только если она действительно нужна.

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

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

Приведу несколько примеров.

  • Если вы строите сложный продукт, позволяющий оптимизировать логистику, то упрощённая версия может не заинтересовать абсолютно никого, потому что «всё это можно сделать в Excel». Это не значит, что идея плоха и её надо менять. Это значит, что её таки нужно довести до более менее удобоваримого состояния.
  • Apple никогда не являлся образчиком «бережливости» и всегда рассчитывал только на свои соображения. И неплохо справился. Может потому и неплохо, что не отдавал проектирование устройств в руки клиентов, которые в этом вообще-то ничего не понимают?
  • Допустим, вы создали страничку и описали, что собираетесь сделать (это уже считается MVP). У вас 10 000 подписок. Ура, можно работать! Но ведь не факт, что вас поняли именно так, как вы думаете. И не факт, что удастся реализовать всё именно так, как задумано. А в итоге, 10 000 пользователей, увидев результат, отвернутся от вас, сказав, что вы обещали другого. И не будет второго шанса создать первое впечатление.
  • Бывает и наоборот. Вы создали описание (MVP) и все вам говорят, «зачем нам ещё один [категория продукта]». Хотя победа может таиться в мелочах — в тех, на которые конкуренты просто неспособны и которые сложно представить. Автор DropBox смог сделать убедительное видео и заинтересовать тысячи людей, убедив, что это не «just another backup system» а нечто более удобное. Но вот Google в своё время вряд ли смог бы кого-то заинтересовать нарисованным окошком для ввода поисковой строки. Нужны были реальные результаты чтобы отличиться от других поисковиков.
  • Так ли хороши ежедневные/еженедельные митинги в вашей команде? Не напоминают ли они обычные совещания, на которых по сути сказать нечего и все только и ждут, когда уже можно будет пойти работать?
  • Вы только начинаете проектировать и каждый день корректируете интерфейсы в своём прототипе. Не странно ли вместе с кодом переписывать тесты, зная, что на завтра они устареют? Может, стоит повременить, пока архитектура немного утрясётся?
  • Вы стараетесь держать продукт минималистичным, не добавляя в него сложных фич. Пользователи довольны простотой использования, разработчики довольны простотой поддержки. Но проверьте, не упускаете ли вы 90% рынка, не давая ему чего-то важного. Многие переходят с BaseCamp на МегаПлан как раз из-за отсутствия нужных вещей (впрочем, 37 signals похоже оттоков не замечают и гордятся своей позицией по сей день).
  • «Мы создаём веб-сервис для работы с векторной графикой». Вы точно уверенны, что пользователю будет удобно пользоваться интернетом для работы с тяжёлыми файлами нужными на его компьютере, а не на вашем сервере? Действительно ли он будет пытаться делать чертежи с планшета или тем более с мобильного*? Уверены ли вы, что поддержка мощных серверов для обработки графики не заставит повысить цену на ваш продукт в 10 раз?
    * подсказка – чертежникам частенько и 20ти-дюймового экрана маловато

В примерах специально столько негатива, не потому что я хочу вызвать дискуссию, а потому что вы его не встретите в соответствующих книгах/блогах/лекциях. Они и понятно, какой смысл агитировать за свою теорию, показывая её недостатки. Из-за этого получается, что новые концепции, которые ещё никто не опроверг, выглядят лучше, чем есть на самом деле (чем они будут выглядеть через 10 лет).

С другой стороны, если впасть в критику, есть опасность ошибиться, просто сказав «методология X не для меня». Проблема может быть в недостаточном понимании, или в неумении применить. Стоит в таких случаях пробовать, примерять новую идею на себя, пытаться её действительно использовать, а не отгораживаться. Может быть, использовать какую-то часть, а не сразу целиком. В общем, сцепить с реальностью и после этого делать выводы. Но не общие выводы «метод X — гавно, метод Y рулит», а конкретные: «метод X не сработал, потому что имели место такие-то обстоятельства, а метод Y выручил, потому что подходил под ситуацию».

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

Автор: Yoschi

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js