Archive for 06.01.2009

Обустраиваем офис и считаем расходы

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

Итого я остановился на том, что работать будет три человека:

  • директор
  • менеджер по продажам
  • курьер

Исходя из минимальных требований охраны труда (приходилось же когда-то учить и экзамены сдавать) нам необходимо по 6 квадратов на сотрудника, т.е. помещение не менее чем 18 квадратов.  Округляю до 20 квадратов, т.к. на двух квадратах надо поставить кофеварку для всех и чайник для меня. Так же директор должен где-то складывать товар, который успел привести со склада, но курьер его еще не забрал.

Замечательно. Есть помещение. Теперь будем всех сажать, эм… рассаживать. Необходимо два рабочих стола, один шкаф для папок,  один обеденный столик,  четыре стула (директору надо красивый, а менеджеру удобный, т.к. менеджер больше всех будет сидеть в офисе).

Вроде всех рассадили. Начинаем работу над связью. Два компьютера для директора и менеджера. А учитывая, что у директора уже есть рабочий ноутбук, то покупать ему ничего не будем. Надо еще принтер купить, что бы распечатывать всякую бухгалтерскую ерунду и всякие картинки.  Это все дело необходимо подключить к Интернету, потому купим просто wi-fi модем и забудем о проводах, а так же будем рады гостям с ноутбуками.  Так же необходимо два стационарных телефона (менеджеру и директору), один мобильный телефон (курьеру).  Надо услуги провайдера по доставке Интернета и телекоммуникационной компании по доставке стационарной и мобильной связи.

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

Вроде все. По деньгам получается следующее (в грн.):

Наименование товара Цена Сумма
Офис 4800 4800
Два рабочих стола 2*600 1200
Шкаф для папок 600 600
Обеденный столик 300 300
Четыре стула 2*150 + 2*300 900
Компьютер 5000 5000
Модем 300 300
Телефонные аппараты 2*150 300
Мобильный телефон 700 700
Услуги: Интернет 220 220
Услуги: две телефонные линии 2*30 60
Услуги: мобильная связь 250 250
Услуги: подключение Интернет и связь 1000 1000
Принтер 1300 1300
Чайник, кофеварка и продовольствие 500 500
Канцелярия и бумага для печати 300 300
Непредвиденные расходы 1820 1820
Всего 20050

А так же ежемесячные расходы на сумму, примерно, 6000грн.

Из предыдущей статьи помним, что з/п в месяц составляет:  ~ $1500, а учитывая, что валюта регулярно скачет, то в гривны переводить будем по курсу 7.0. Итого:  10500грн. Так же есть еще расходы и налоги на ФОП. Я не силен в бухгалтерии, но мне называли ориентировочно 40%. Итого еще 4000 уходят.
Подсчитывая наши расходы на офис и персонал, получается, что:

  • одноразовое вложение: ~20000грн.
  • ежемесячные расходы: ~6000грн.
  • ФОП и расходы, связанные с ним: ~15000грн.

Итого: 20 тыс. грн. отдаем сразу и каждый месяц еще по  21 тыс. грн.

Это уже конечно тема не этого поста, но интересно посчитать, сколько ж надо продавать, что бы такое получилось.
Допустим, окупиться все должно через 10 месяцев, т.е. 20000 делим на 10 и получим, по 2000 в месяц. Расходы в месяц 21000 + 2000 = 23000.
Допустим, доход от продажи ноутбука будет 10%, т.е. в месяц это должно быть 23000. Значит, мы должны делать оборот на 230 тыс. грн.  Это где-то 30-45 ноутбуков в месяц. Ну что же… Не много, не мало…

В следующем посте посчитаю сколько примерно денег найдо потратить на рекламу и раскрутку.

Техническое задание

Техническое задание - в поисках истины

Было недавно очень много споров вокруг технического задания. Все судили о ТЗ со своей стороны. Я попытался собрать это все в одну лирическую статью.

Что такое техническое задание?

Cогласно Wiki:

Техническое задание (ТЗ, техзадание) — исходный документ для проектирования сооружения или промышленного комплекса, конструирования технического устройства (прибора, машины, системы управления и т. д.), разработки информационных систем, стандартов либо проведения научно-исследовательских работ (НИР).

Cогласно Яндекс.Словари определение более широкое (первая часть с Wiki повторяется один в один):

…ТЗ содержит технико-экономическое обоснование разработки, основные технические требования, предъявляемые к сооружению или изделию, и исходные данные для разработки; в ТЗ указываются назначение объекта, область его применения, стадии разработки конструкторской документации, её состав, сроки исполнения и т. д., а также особые требования, обусловленные спецификой самого объекта либо условиями его эксплуатации. Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчётов и моделирования.

Есть определения ТЗ, которыми все пользуются. Оспаривать определения глупо и бессмысленно: «Об определениях не спорят, о них договариваются»(с).

В этой статье я хочу отойти от определений и приблизиться к реальности разработки сайтов.

Я склонен считать, что техническое задание – это документ. Важно, что на нем ставятся подписи и печати, а значит, имеет юридическую силу и при необходимости к этому можно и нужно прибегнуть.

«Кому надо техническое задание?» – вопрос достаточно сложный. На абзац Выше я написал, что это документ, а значит, он нужен как заказчику, так и исполнителю. Давайте детальнее.

Зачем техническое задание менеджеру? В нем менеджер проекта излагает все касательно разрабатываемого продукта. Это делается из следующих соображений:

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

Обязательно ТЗ надо разработчикам, т.е. дизайнеру, верстальщику, программисту и т.д. Надо оно им только из одного соображения: перед тем как делать, надо четко понимать, что ты делаешь и, что должно быть в результате. Согласно методологии постановки целей S.M.A.R.T, цель должна быть измерима. А это в основном цифры. Вот в техническом задании эти цифры и прописываются. Т.е. если клиент сказал, что «сайт должен загружаться быстро», то в ТЗ это описывается примерно так: «Размер страницы без графики, загруженной пользователем, должен составлять не более 50Kb».

Остается только один вопрос: надо ли техзадание клиенту? Я считаю, что в большинстве случаев – не надо! Техническое задание отдавать клиенту разумно в том случае, если клиент может разобраться в нем. А если контактным лицом со стороны клиента является «девочка-маркетолог», то некоторые разделы она вообще не сможет понять как таковые. В результате Вы, конечно, подпишите с клиентом такое ТЗ, но это будет субъективный документ. С другой стороны клиенты разные и если не зажимать их в рамки технического задания, то они будут пить кровь очень долго и мучительно. Тут выбор за Вами.

Что должно быть в техническом задании?

В последнее время часто слышу вопросы: «Техническое задание одно на всех, или по одному на каждого?». На практике я писал и одно на всех и по одному на каждого. Это было что-то вроде эксперимента. Изначально у меня был вопрос: «А как разные люди могут создать что-то одно, опираясь на разные цели/задачи?». Оказалось, что могут.

«Одно ТЗ на всех». Я остался сторонником именно этого подхода. В одном документе описывается, как Сайт должен работать, выглядеть и т.д. Каждый разработчик должен полностью ознакомиться с документом, что бы понимать полную картину. Часто бывает, что ошибки командные, а не чьи-то конкретные, потому и необходимо, что бы команда знала всю картину и не допускала подобные ошибки. Как пример: «Размер страницы без графики, загруженной пользователем, должен составлять не более 50Kb» – этот критерий можно отнести как к дизайнеру, так и к верстальщику. Если в результате страница весит 70К, то дизайнер с верстальщиком могут очень долго играть Вами в футбол.

«По одному на каждого». Как показала практика это самый лучший способ управление проектом, когда команды еще нет. Коллектив есть, а команды нет. Директивный метод управления – классика. Для каждого Вы пишете ТЗ, и каждый его делает. Недостаток подхода в том, что у Вас это занимает очень много времени, которое Вы могли бы потратить на что-то более полезное. Так же Вам приходится изучать нюансы работы каждого, а быть дизайнером, верстальщиком, программистом в одном лице – это плохо, и уж явно это не проектный менеджер в веб-студии.

Не зависимо от «одно на всех или по одному на каждого», ребром всегда становится вопрос детализации технического задания. Тут спорить можно очень долго и безнадежно. Потому что детализация технического задания напрямую зависит от квалификации персонала. На примере программиста: если программист знает спецификацию формата CSV-файлов, то можно не углубляться в технологию как его правильно парсить. И наоборот.

Идеальное техническое задание – миф или реальность?

Нельзя линейкой измерить идеальность. Должны быть критерии. Пока критериев нет – это провокационный вопрос.

Техническое задание и другие документы.

Наряду с техническим заданием обычно подписываются и другие документы. Однозначно подписывается договор. Возможно, подписывается календарный план, который согласно ГОСТ 19.201-78 уже, в каком-то виде, есть в ТЗ и описывается в разделах: стадии и этапы разработки, порядок контроля и приемки. Осталось добавить даты и все.

Часто в техзадании описывается концепция проекта и многие другие – НЕНУЖНЫЕ – вещи. Концепция проекта имеет совершенно другое назначение и потому не стоит включать концепцию в техническое задание. О том, что такое концепция и чем она отличается от ТЗ можно узнать из замечательного топика на Хабре.