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

Я держал в руках стакан воды и чувствовал себя немного неловко. Прямо напротив меня сидел наш приезжий гость — господин Ван. Он пробивал себе путь в другом месте и, по слухам, в последние годы добился немалых успехов. Видя, как бурно развивается мобильный интернет, он, естественно, захотел влиться в это движение. Хотя сфера деятельности господина Вана была несколько связана с IT, он так долго не касался технологий, что некоторые вещи были ему незнакомы, поэтому он всегда хотел проконсультироваться со мной — старым программистом, который более десяти лет проработал на передовой разработки. Более десяти лет разработки могут означать многое, но это не суть, так что давайте временно проигнорируем эту деталь.

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

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

Я осторожно сказал: «Честно говоря, точно сказать не могу. У меня тоже не так много опыта в этой области. Хотя я занимался разработкой приложений, это сильно отличается от этого. Мне пришлось бы подробно проанализировать всю логику, прежде чем я смог бы оценить время».

Президент Ван, похоже, не впечатлился моими словами. Он потряс телефоном и сказал: «У меня немного требований; на самом деле это проще, чем вот это». Указывая на определённые места на экране, он продолжил: «Это, это и это можно убрать. Мне нужен просто такой список, с деталями внутри, где можно просматривать и редактировать...»

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

После короткой паузы президент Ван сказал: «Конечно».

«Какая авторизация? По логину и паролю, или вход по телефону, или сторонняя авторизация вроде QQ, Weibo или WeChat, которой можно воспользоваться?»

На этот раз президент Ван, казалось, на мгновение задумался: «Как штука для мобильного интернета, вход по телефону, я думаю, точно нужен. QQ, Weibo — а, WeChat, WeChat тоже, конечно, нужен... Ах да, вы раньше упоминали имя пользователя и пароль; это, пожалуй, тоже нужно».

Я плавно продолжил спрашивать: «Тогда вам понадобится регистрация. Если вы планируете использовать вход по телефону, вам нужно будет найти SMS-платформу. Для входа через WeChat сначала нужно пройти корпоративную верификацию. К тому же, при входе по логину и паролю понадобится функция восстановления пароля, верно?»

«Само собой».

«При нескольких способах входа нужно придумать разумную логику, чтобы их „интегрировать“. Самый распространённый подход — конечно, привязка аккаунта: например, привязать аккаунт к номеру телефона, чтобы можно было входить в тот же аккаунт по номеру телефона. То же самое касается входа через WeChat. Но сегодняшние пользователи мобильного интернета очень не любят процесс регистрации, поэтому часто требуют входить напрямую по телефону или через WeChat, а регистрация должна выполняться автоматически. Учитывая эту ситуацию, если пользователь сначала войдёт через WeChat, а затем войдёт по номеру телефона вместо привязки, это создаст два разных аккаунта, которые уже нельзя будет „интегрировать“. Нам нужно придумать относительно полное решение...»

Президент Ван, казалось, несколько потерял терпение от моих слов: «Неужели всё действительно должно быть настолько сложно? Посмотрите на это приложение — разве в нём уже нет всего этого?»

«Вы пробовали это, чтобы проверить, существует ли проблема, которую я описал ранее?»

Но Президента Вана, казалось, эта проблема не беспокоила. Он хотел знать лишь, сколько времени займёт создание такого приложения, и, конечно, сколько это будет стоить — это тоже его заботило. Он уверенно сказал: «Чего бояться проблем? Что такое трудности? Я верю, что все их можно решить. Но время критично; нужно действовать быстро. Наши конкуренты не будут нас ждать. Вот такое дело — подумай, сколько времени это займёт?»

Судя по его манере держаться, он был именно тем успешным человеком, который добился больших высот, и мне, простому программисту, действительно было трудно говорить в его присутствии. Я хотел было продолжить объяснять ему, насколько важны детали, но он перебил: «Нет, не нужно настолько точно. Просто оцени диапазон — две недели? Или два месяца?»

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

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

====================== Не слишком гламурный разделитель ======================

«Сколько времени занимает создание приложения?» На этот вопрос, вероятно, ответить сложнее, чем предсказать, сколько дней осталось жить человеку. Как можно ответить на такой вопрос, имея так мало информации?

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

Пользователи видят только приложение. Если они пользуются iOS, они могут никогда не столкнуться с Android и не осознавать, что помимо версии для iOS разработчикам нужно сделать ещё и версию для Android, а может, и версию для Windows? Это, несомненно, означало бы ещё больше работы. Или, возможно, веб-версия может делать всё? Возможно, вы не стали бы так думать, если бы действительно создали её. К тому же, может ли такая модель, как мини-магазин WeChat, действительно подходить для всех случаев? Более того, если только нет сбоя сети, обычные пользователи даже не замечают существования серверов. Серверы всегда молча работают для пользователей круглосуточно, и сложность их разработки, вероятно, не меньше, чем у самого приложения. А для поддержки приложения нужны люди; когда оно разрастётся, возможно, вам даже придётся сформировать профессиональную команду. Им нужен «бэкенд», чтобы просматривать и обрабатывать данные в любое время. Если вам нужно просматривать и обрабатывать данные в любое время и в любом месте, возможно, придётся создать отдельное приложение для бэкенда.

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

Помимо этих основных аспектов, в деталях также много неопределённости, поэтому особенно важна зрелая команда. Опытный разработчик будет знать — хотя бы приблизительно — с какими проблемами придётся столкнуться при разработке, какие из них простые, а какие могут занять много времени. Это зависит от опыта. Я часто говорю фразу: ""Не говорите легкомысленно, что что-то просто, если вы никогда этого не делали."Отношение "предполагать, что это просто" не приносит пользы проекту. Если вы не уверены, обратитесь к кому-нибудь, кто имеет опыт в этой области. Даже если вы не получите конкретного ответа, вы по крайней мере получите общее направление. Исследуйте в этих направлениях, и вы узнаете о проблемах, с которыми столкнётесь, — хотя часто всё равно не обо всех.

Что касается «недооценки сложности», есть классическая история из моей предыдущей компании. Тогда был небольшой проект: мы планировали добавить поддержку нескольких языков в программу, которая уже работала на приборах и поддерживала только английский. Программа была небольшой, и объём задействованного контента тоже был не слишком велик. Инженеры сначала думали, что это просто задача по переводу, которую можно выполнить максимум за две недели. Но как только они начали, то обнаружили, что это совсем не просто. Во-первых, перевод должен был выполняться профессионалами; мы сами не смогли бы сделать это хорошо — никто из нас не владел европейскими языками в совершенстве. Затем последовало преобразование единиц измерения: некоторые страны используют метрическую систему, некоторые — имперскую, поэтому это тоже нужно было учитывать, включая форматы отображения дат. Внезапно появилось неизвестно сколько дополнительной работы. Когда это в основном было сделано, они обнаружили, что немецкие слова слишком длинные и не помещаются на экранах приборов — они выходили за пределы области отображения. Поэтому они скорректировали шрифты и сократили контент, а также провели совещания, чтобы обсудить это N раз туда-сюда. Наконец, когда они захотели выпустить релиз, то обнаружили, что из-за всех этих изменений размер программы стал намного больше, и хранилище некоторых приборов не могло его вместить. В этот момент все растерялись. Поэтому они оптимизировали и упрощали, и программа начала становиться немного запутанной. В конце концов они едва прошли проверку отдела контроля качества и наконец выпустили её — только чтобы понять, что на это ушло целых полгода. Оглядываясь назад сейчас, важной причиной того, что это заняло так много времени, был недостаток опыта; незнакомство с многоязычностью и интернационализацией привело их ко многим неверным путям. Так что, как я упоминал ранее, наличие зрелой команды особенно важно.

При оценке времени проекта мы часто учитываем только «время, потраченное на написание кода», упуская время, потраченное на споры с начальниками или клиентами, анализ требований, проектирование, тестирование и исправление ошибок. В сумме эти затраты обычно намного превышают время, потраченное на написание кода. Лично я не спешу называть короткий срок сдачи только для того, чтобы угодить начальнику. Почему? Потому что это просто невозможно — так зачем лгать? Если на разработку новой функции требуется неделя, я обычно удваиваю этот срок, и это ещё относительно «неконсервативно».

Даже если учитывать только время, потраченное на написание кода, его часто недооценивают. Начальник или клиент может быть недоволен тем, что вы разработали — возможно, вы неправильно поняли его функциональные требования, или интерфейс тормозит, или цвет иконки некрасивый. Вы разработчик, а не графический дизайнер. Хотя в крайнем случае вы, может быть, и сойдёте за дизайнера, но всё равно вы не профессионал. Что ещё важнее, заниматься UI-дизайном и созданием изображений тоже отнимает много времени. Когда вы отчаянно бьётесь над «одним пикселем», разве вам не хочется, чтобы в команде был дизайнер? В такие моменты нужно напоминать начальнику: приходится идти на некоторые компромиссы между временем и функциями. Начальник, конечно, будет недоволен, но у него нет выбора, кроме как пойти на компромисс по некоторым функциям. Хотя это позволяет проблемному проекту запуститься раньше, это также даёт начальнику отличное оправдание для будущего провала проекта: «Наши инженеры были слишком плохи; они сделали не то, что я им говорил».

Помимо жалоб на то, что сделанное вами недостаточно красиво, начальники или клиенты также поднимут много других вопросов: Можно ли переделать этот интерфейс под множественный выбор? Можно ли добавить функцию уведомлений? Должен быть статус прочитано/непрочитано. Можно ли сделать интерфейс немного плавнее? Почему программа "упала" вчера вечером... В требованиях просто перечислены функции, но не сказано, насколько красивым должен быть этот UI, а также не сказано, что стабильность программы должна быть хорошей, не говоря уже о том, какой пропускной способности нужно достичь. И конечно — что, возможно, важнее — о безопасности тоже не упоминается. Вы пугаетесь: верно, если бы были хакеры — нет, достаточно, чтобы злонамеренный пользователь с хотя бы небольшими техническими знаниями захотел завалить наш сервер, это было бы слишком легко, а я не принял ни одной из этих защитных мер! К счастью, проект всё ещё слишком малоизвестен, так что пока это можно не учитывать. (Похоже, большинство приложений не доживают до момента, когда им нужно об этом задуматься.)

Все эти вещи — называете ли вы их функциями, деталями или надёжностью — не являются чем-то, что может автоматически вырасти из почвы; все они требуют времени на обдумывание и реализацию. Некоторые — это даже работа по "системной инженерии". Если вы лечите голову, когда болит голова, и ногу, когда болит нога, система будет полна "летающих проводов" повсюду, что, несомненно, оставит множество скрытых опасностей для будущего сопровождения. Вы, инженер, учли их все? Не говоря уже о "незначительном" вопросе о низкопроизводительном компьютере, который начальник купил вам для экономии затрат и который сводит вас с ума целыми днями.

====================== Не такая уж и навороченная разделительная линия ======================

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

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

Источник: http://www.cnblogs.com/guogangj/p/4676836.html