Управление собственным проектом: работа с программистом
Posted on 16/04/2014
Большой спрос на услуги веб программирования спровоцировал появление огромного количества программистов, желающих этот спрос удовлетворить.
Допустим у вас есть пара лишних тысяч долларов, и вы хотите запустить свой собственный продукт в интернете. Это может быть сайт, рассказывающий про существующие товары и услуги, веб приложение для обработки пользовательских данных или все, что вы захотите. У вас есть идея, есть желание, есть огонь в глазах и четкое понимание того, как должен работать ваш продукт, но нет никакой возможности сделать это самостоятельно. Уверен, в такой ситуации оказывались и оказываются миллионы людей по всему миру.
Речь пойдет о тех проблемах, с которыми сталкивается бизнесмен при общении с исполнителем - разработчиком веб приложений. Данная статья не затрагивает тематику поиска подходящей кандидатуры, но затрагивает важные аспекты процесса взаимодействия с уже нанятым программистом.
Цель и задачи
Не стесняйтесь поделиться с программистом общими соображениями относительно того, для каких целей создаются те или иные части системы. Все программисты обладают аналитическим мышлением, позволяющим выделять детали из объекта обсуждения.
Технологии
В своих рассуждениях я опираюсь исключительно на PHP в качестве основной технологии для веб разработки. Пара PHP/MySQL - самое простое и распространенное средство реализации ваших задумок.
Визуализация желаний
Любой технический специалист с легкостью понимает схемы, графики, рисунки. Большой объем текста в качестве описания того, что нужно делать - это хорошо в том случае, если вы рассказываете про детали работы алгоритма или любой другой последовательности, которую с легкостью может визуализировать пятиклассник. Когда же речь заходит о взаимодействии конечного пользователя с будущим продуктом/системой, то тут не обойтись без средств визуализации.
Одно из простых средств, которое я рекомендую, - это утилита Pencil. (http://pencil.evolus.vn/).
Например, вы с легкостью за несколько минут можете создать следующий макет страницы входа в систему. Для этого не понадобятся какие - либо технические навыки.
Имя подобные макеты, даже у вас будет более полное представление о том, как и что должно работать в системе. Важно еще то, что в случае, если вы хотите иметь сложный интерфейс, который будет видоизменяться в зависимости от поведения пользователя, то тут необходимо иметь прототипы всех возможных состояний интерфейса. Сейчас я затронул очень глубокую тему, которая на Западе называется UX (User Experience) и которая просто обожествляется, превозносится над технической стороной проекта.
Про изобретение колеса
Подобно врачам ИТ специалисты разделяются на типы: дизайнер, верстальщик, программист. Некоторые люди совмещают в себе несколько способностей: например, можно часто встретить программиста, который умеет верстать HTML и CSS, или дизайнера, который кроме графических навыков работы с Photoshop и другими графическими пакетами, способен верстать HTML и CSS. Еще реже можно встретить дизайнера, верстальщика и программиста в одном лице.
Моя точка зрения заключается в том, что более узкий специалист может обладать более глубокими познаниями в своей области, но если ваш бюджет не позволяет нанять отдельных специалистов, то решать вам.
Не секрет, что многие интернет проекты используют готовые составные части (например, Javascript библиотеки). Наверняка, имея творческий запал и желание построить идеальный продукт, вы захотите, чтобы ваша система работала на всех устройствах и во всех браузерах. Вам на помощь придут уже готовые CSS - решения типа Foundation или Bootstrap. Любой backend программист сможет использовать такие фреймворки после 30-минутного чтения мануала.
Отдельно хочется отметить PHP - фреймворки, работу с которым я уже затрагивал в одной из своих статей.
Стиль кодирования
Совершенно естественно, когда над одной системой в разные промежутки времени работают несколько человек. В такой ситуации забота о правилах, согласно которым программный код должен выглядеть определенным образом, просто необходима.
Мое личное предпочтение - это стиль Kohana, определенный вот здесь - http://kohanaframework.org/3.3/guide/kohana/conventions.
Топтание на месте
Безусловно, ваш нанятый работник - своего рода заложник обстоятельств, диктуемых вами, но только представьте строителя, который занимаясь фасадом здания, узнает о том, что компания - застройщик решила сделать здание шире на несколько метров. Вот - вот, ощущение не из приятных.
Есть целый подход под названием “гибкая разработка” (Agile), который подразумевает использование циклов, до и после которых получается рабочая версия системы. Разбивайте процесс работы на части. Это поможет и вам и вашему нанятому работнику чувствовать себя комфортнее. По итогам каждой задачи тестируйте вместе с вашим программистом систему и добивайтесь полной работоспособности на каждом ее этапе.
Возможно, даже бюджет можно разрезать на соответствующие части.
Самый идеальный случай - это когда вы можете себе позволить:
- 1) Нанять графического дизайнера, который создаст PSD макет на основе ваших прототипов (например, из Pencil);
- 2) Нанять верстальщика, который создаст HTML/CSS файлы на основе PSD макета;
- 3) Нанять программиста, который уже “оживит” всю систему: соединит бездушный HTML с базой данных, добавит Javascript - вставки, если это не сделал верстальщик.
Напомню о том, что два первых этапа можно с легкостью пройти, приобретая готовый шаблон на ресурсах типа themeforest.net. Он вам будет стоить от 15 USD, но сэкономит уйму времени.
Про сохранность файлов
Умением пользоваться системами контроля версий сегодня уже никого не удивишь. Bitbucket и Github - одни из самых известных. Потратье немного времени на понимание принципов работы данных систем, чтобы понять их пользу от их внедрения. Одна из причин использования данных систем - это возможность резервного копирования исходных файлов проекта. Другая причина - это возможность безболезненно отменить только что сделанные изменения в случае, если обнаружились внезапные проблемы с новым функционалом.
Для программиста будет возможность увидеть, какие участки кода он изменил, поэтому процесс отладки может быть ускорен.
На вышеприведенном изображении - пример изменений, взятых из Github.
У многих программистов уже вырабатывается привычка работать с Git-подобными хранилищами в качестве резервных копий. Уверен, такие навыки для программиста - это нечто из серии must have.
Про мелкие детали
Как бы детальны вы не продумывали процесс работы вашего сайта или системы, все равно будут детали, которые скрыты внутри. Любой программист всегда задаёт много вопросов. Это важный знак того, что вы имеете дело с нужным человеком. Пусть это выглядит занудством, иногда даже вопросы могут повторяться, но всё это - верный признак того, программист думает и пытается понять, как ему следует действовать.
Очень удобно, если вы будете обсуждать такие детали, разделяя каждую тематику. Например, очень удобно для этого подходит basecamp или даже github issue tracker. Не всегда наглядна получается простая переписка по электронной почте, если речь идет о длинном диалоге.
Стоит помнить о том, что неучтенные вами детали могут затягивать выполнение того или иного этапа работы. Идеальным вариантом будет, если к тем временным рамкам, которые определил программист, вы добавите 20-25%. Это достаточный запас времени для обоих сторон.
Начиная какой - либо проект, вы как менеджер обязательно должны иметь какое - либо представление о том, что вы делаете, но ваш исполнитель - это обязательно более квалифицированный специалист в этой области, чем вы. Данное представление - один из элементов делегирования, описанных почти в каждом учебнике по менеджменту.
Про амбиции
По-моему, Доннальд Кнут говорил о том, что “преждевременная оптимизация - это корень всех зол”.
Любой суперуспешный проект переписывался и переписывается много раз. Не ставьте сразу заоблачных требований к своему проекту.
Есть множество способов улучшить сайт/систему, но стоит ли тратить драгоценные ресурсы на нулевом этапе?!
Например, зачем использовать Amazon S3 в качестве хранилища графики, если ваш текущий трафик - 10 посетителей в день.
Мне кажется, очень мудро следовать идеи MVP (http://en.wikipedia.org/wiki/Minimum_viable_product).
Про личные взаимоотношения
Все еще вспоминается один из моих клиентов, который каждый час задавал мне вопрос “How is it coming along?”. Думаете, вы догадываетесь, чем закончилась такая работа. Конечно, было трудно объяснить такому товарищу о том, что мне иногда и в туалет ходить, а иногда - поесть. Один из моих университетских преподавателей говорил так: “В неудаче - 95% вины менеджера, а только 5% - исполнителя”.
Ни в коем случае не хочу утверждать, что программист в качестве исполнителя никогда не несет какой - либо ответственности, но тон и стиль работы задается менеджером проекта.
Всё вышеприведенное - попытка трансляции собственных мыслей и опыта в некие советы. Насколько хороши они, конечно, решать вам. Уверен, самое главное - это получать удовольствие от того, что и как делаешь.
Сергей Кошкарёв
16 апреля 2014