Все что написано ниже условно и являет собой лютую отсебятину даже без налета академичности. Не ищите прямых параллелей с книжными описаниями жизненного цикла. Их и так можно посмотреть в книжках.
1. В начале была боль
Началом любого продукта есть боль. Или зуд. Или и то и другое. Нужно запомнить одну простую вещь:Целью проекта есть продукт. Целью продукта есть избавление пользователей продукта от боли. За что пользователи платят.
Все! Я нигде не написал о коде. Что подразумевает что код и кодирование самоцелью быть не может. Извините. Перефразирую:
Код, документация, исполняемый файл не есть самоцелью в профессиональном программировании. Конечная цель любого проекта- избавить пользователей от боли или зуда и получить за это деньги.
Но вернемся к боли. Это может быть боль от реальной сиюминутной проблемы (например замена бумажного документооборота с беготней по этажах с пухлыми папками). Это может быть фантомная боль (боль придуманная маркетологами, хотя на пустом месте и она возникнуть не может). Это может быть боль о существовании которой узнают когда маркетологи и разработчики подскажут (например многим очень хочется иметь квадрокоптер, но захотелось только после того как квадрокоптеры вообще появились). По большому счету не важно какая это боль: от ежедневного неэффективного перекладывания тяжеленных папок или от осознания того что ты ощущаешь что не настолько "think different" и вообще крут как тебе бы хотелось или зуд от желания иметь игрушку которую так хотел в детстве, но ее не было. Главное что есть потребность. И за ее удовлетворение ты готов платить.
2. ...потом была идея
Люди способные уловить вышеописанную боль и сгенерировать идею как сделать так чтобы от боли избавиться становятся гениальными маркетологами. Люди способные кроме всего этого еще и реализовать эту идею (не важно реализовать самому или кого- то нанять) становятся успешными бизнесменами с виллами, яхтами и всеми прочими прибамбасами соответствующими статусу.3. Добавим денег
Хорошо это или плохо но с древних времен универсальным мерилом ресурсов являются деньги. Деньги позволяют нам айтишникам обменивать наши абстрактные мозгочасы на вполне конкретную вкусную еду, красивые цацки и прочие ништяки. Почему- то многие упускают тот момент что на работе нам платят деньги и эти деньги где- то надо брать. То есть если у Вас денег стало больше у кого- то их стало меньше!Давайте подключим несложную арифметику. Просто для примера. Возьмем команду из десяти разработчиков и посмотрим сколько такое удовольствие стоит в год:
1. Зарплата. Пусть средняя по команде зарплата будет 2000$ (это ну очень скромно). Налоги (по местной традиции платит фирма) добавят сюда еще по 100-400 (пусть будет 100). И того на зарплату в год будет 2100*10*12 = 252 000$. По странному стечению обстоятельств столько стоит дом моей мечты... Мда...
2. Но это же еще не все. Команде нужны компьютеры, столы, стулья. Посмотрим на потолок, прикинем аммортизацию, прикинем что компьютер года три менятся не будет. И того с потолка еще где- то 300$ на брата. Сумма возросла до 255 000$
3. Офис. За офис нужно платить. За само помещение, уборку, охрану, доставку воды.
4. staff. В любой компании есть бухгалтерия, hr, системные администраторы...
5. Чуть не забыл про медстраховку.
Еще раз глубокомысленно посмотрим на потолок, припишем к проекту и округлим до 300 000$
И даже при таких крайне оптимистических подсчетах сумма получается не маленькая для мобильной игры ценой в $4,99 без вычета процента магазина.
Это я к тому что Ваше время это чьи-то деньги. Это я не "в оправдание буржуев". Я просто констатирую факт того что реализация программного проекта вещь дорогостоящая. Имейте ввиду когда подумаете об организации собственной "багодельни". Я предупредил.
Тут мне можно возразить что можно продукт и дома вечерами сделать. Можно. Но не всякий. И сложно это в одиночку. А найти альтруиста-дизайнера, альтруиста-тестера и т.д. задача тоже не из легких. Учитывая что к моменту когда эти люди уже что- то хорошо умеют они предпочтут вечера проводить с женой и детьми. И еще по окончанию может потребоваться дорогостоящее лечение :) Плюс практически любой "молодой и перспективный стартапер" рано или поздно не сможет разрываться между официальной работой и своим детищем и вынужден будет выбирать. И часто выбирают "свое родное". И пока это самое "свое родное" принесет сколько-нибудь денег нужно что- то кушать. И семью кормить. Короче говоря, так или иначе, в той или иной форме деньги Вы потратите. И деньги не малые. И без денег как ни крути продукт не получится.
4. Планируем
В принципе про планирование можно было бы упомянуть и раньше, но предыдущий текст должен был плавно подтолкнуть к тому что совсем без денег планировать что- то вообще бессмысленно. К этому моменту будем считать что деньги в принципе есть. А теперь исходя из того количества денег которые мы можем потратить приступаем к планированию.С самого начала у нас будут жуткие метания между хотелками по функционалу и бюджетом. И тут либо скрепя серцем отложить покупку недвижимости или умерить желания по функционалу.
О! Чуть не забыл! Все же помнят что большинство проектов в срок не делаются? Тут самое время это учесть и заранее приготовится к дополнительной утрате либо денег либо функционала.
Тут у нас вотчина PMов. Все что так любо их сердцам: выбор методологии (waterfall/agile), технологий, инструментов, рисование Ганта / написание беклога (по вкусу), и т.д. И, что самое противное, ошибки допущенные на этой стадии часто обходятся очень дорого. Особенно допущенные в фундаментальных вещах (в технологиях и методологии.
Ремарка: Вот только не нужно меня тыкать в agile и говорить что там планирование нету. Есть оно. И product backlog и user stories когда- то создать нужно. Да и сам процесс проектных решений по выбору agile и технологий разработки тоже как не крути а часть процесса планирования.
5. Прототипируем
"Никакой код не считается достаточно стабильным пока не будет хотя бы раз полностью переписан"Очень вольное изложение высказывание автора llvm
В наших краях за неимением большого количества продуктовых компаний и стартапов (а соответственно продуктов) прототипирование это такая "недостижимая мечта". Все хотят прототипировать но лишь единицам на это выделяют время.
Спросите у любого после окончания проекта смог бы он во второй раз сделать быстрее и лучше? Вот чтобы преиграть все с начала. Чтобы учесть опыт хождения по граблям и ошибки. Все, абсолютно все скажут: да, смог бы. Лучше и быстрее.
Теперь вспомним утверждение "время-деньги". И еще добавим мое голословное утверждение что "рефакторинг обходится дороже написания функционала". Сопоставим эти два утверждения. И получается что иногда дешевле потратить немного время-деньги для того чтобы потом сэкономить время-деньги.
То есть мы прикидываем насколько быстрее и лучше в итоге получится продукт если мы потратим, скажем, месяц на выявление граблей. И получится далеко не всегда прототипирование выгодно.
Короче говоря: прототипирование должно быть целелесообразным т.е. выгода по времени и качеству выполнения всего проекта должна превысить потери времени на прототипирование.
Ремарка №1 (для кодеров и архитекторов) : Не смотря на кучу уверений и понимания "как правильно" практически всегда большая часть или вообще весь прототип превращается в готовый продукт (см. ниже). Соответственно говнокода в прототипе должно быть чем меньше тем лучше! И архитектура должна присутствовать. И учитывать такую возможность!
Ремарка №2: Не путайте прототип и демку! Демка- демонстрация потенциальных возможностей. Прототип- набросок архитектуры и функционала. В первом случае говнокод допустим и необходим (быстрее покажем- быстрее оценят). Во втором нужно уже и об архитектуре подумать.
Ремарка №3 (для РМов): Одним из сложнейших упражнений в "проектном кунг фу" является убеждение заказчика в том что прототип должен быть переписан желательно весь. Для человека который платит за продукт совсем не очевидно почему нужно "поломать" то что "уже работает". Имейте это ввиду, готовьте заказчика заранее. А то потом уродливый зародыш архитектуры обрастает костылями и подпорками.
И того: С одной стороны нужно быть готовым к тому что прототип выльется потом в продукт, с другой- сопротивлятся этому.
Ремарка №4: Не ленитесь и не бойтесь после прототипирования пересмотреть архитектуру и готовтесь к перепланированию. Оно для этого и делалось! Не ленитесь перепланироваться с учетом того что вы уже лучше знаете где стоят грабли. Еще раз: не только ревизия архитектуры и рисков но и ревизия всего остального(иногда вплоть до юзкейсов и user stories)!
И немного о стартапах. Вот где протоипирование необходимо так это тут! Типичный случай: денег на прототип хватает а вот на продукт уже нет. Соответственно нужно что-то среднее между прототипом и демкой для показа. Тут без вопросов- нужно (с учетом всех ремарок выше).
6. Ну наконец- то делаем!
Тут я вообще почти ничего писать не буду. С одной стороны этот процесс уже многие знают и так. С другой- это тема далеко не одной записи в блоге.7. Проверяем
Любая разработка сейчас- процесс итеративный. В идеале мы постоянно проверяем что же у нас получается. Реже (в waterfall) или чаще (в SCRUM). Но рано или поздно приходит тот момент когда мы говорим себе "все, оно готово", ну или "Its alive! Alive!!!" и смотрим на продукт целиком как на готовую целостную вещь. Самое время для себя честно признаться соответствует ли то что получилось нашим ожиданиям. И именно мера эта соответствия и есть качество выполнения проекта. Тут и функционал и сроки и бюджет. Но это не качество продукта. (это сейчас было мое личное мнение).8. Продаем
Теперь нужно сделать так чтобы нам за это все дали денег. Если кто- то другой уже качественно избавил людей от боли- мы проиграли. Если боль изменилась или стала не актуальной- мы проиграли. Если людей у кого болит меньше чем мы думали- мы проиграли. Если люди не знают ничего о нашем "лекарстве" они его не купят. Мы опять проиграли.Но если мы правильно угадали проблему, одними из первых ее решили и люди об этом узнали и при этом заработаем больше чем потратили- тогда поздравляю, мы молодцы и все сделали правильно. И уже соотношение затраченного к полученному есть качество продукта.
9. Делаем выводы
Делать выводы нужно всегда. Человек учится почти исключительно на своих ошибках. Следствие этих ошибок- опыт. Это следы от шишек на лбу после хождения по граблям которые напомнят Вам где эти грабли разбросаны. Когда Вас нанимают на работу (не на позицию Jr. Software Developer) они покупают не только ваши мозги но и ваш опыт. И чем выше Вы в иерархии тем больше покупают именно опыт.Из любого проекта нужно опыт извлекать. И позитивный и особенно негативный. Это всех касается- от программистов до владельцев бизнеса.
Поэтому закончив проект притормозите на один день, обсудите пусть в неформальной форме что вы сделали и как. Что было хорошо, но что более важно, что бы вы не сделали вернувшись назад.
Немає коментарів:
Дописати коментар