Как строить отношения с разработчиком?

123 4
Ч
На сайте с 16.12.2010
Offline
362
2304

Привет!

Как правильно построить отношения с разрабом?

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

Сейчас встал вопрос разработки определенного веб сервиса с нуля.

Понятно, что начинать надо с ТЗ.

А вот дальше как?

1. Дизайн, как я понимаю, это последняя стадия, т.е. он вешается на уже готовый функционал.

А куда выводить результат работы, пока нет дизайна? Ведь страницы-то по сути нет.

Как это сделать так, чтобы потом дизайнер и верстальщик не переделывали все заново?

2. Никто не любит копаться в чужом коде. Написал программер код, а потом с ним что-то случилось и он пропал. Как продолжать работу, если кодер новый, а код старый?

3. Выставлять ли разрабам требования по языку кода? ПХП, Java? По версии языка?

4. Как понять, что код оптимален по быстродействию и алгоритму, по дублям страниц и тд? Если торомза будут из-за неоптимального кода, они ведь, будут лечить, что дело не в коде, а так и должно быть, это ограничения языка, хостинга и тд, и по-другому не сделать.

5. Кто кроме кодера, дизайнера и верстальщика учавствует в создании веб сервиса?

6. Стоит ли отдавать всю работу одной студии (человеку) или лучше разбивать по разным исполнителям? Мне кажется, что лучше разбивать.

7. Фрилансер или студия? Я склоняюсь в фрилансерам.

Artisan
На сайте с 04.03.2005
Offline
351
#1
Четверьг:
Как правильно построить отношения с разрабом?

Вы забыли самый важный пункт в списке.

ПЛАТИТЬ !!!

www.leak.info / ДАРОМ линки конкурентов и забытых доменов
Ч
На сайте с 16.12.2010
Offline
362
#2
Artisan:
Вы забыли самый важный пункт в списке.
ПЛАТИТЬ !!!

Продолжая список моих вопросов надо было написать так?:

8. Платить?

У меня же список вопросов, а не утверждений.

dglstyle
На сайте с 24.03.2011
Offline
70
#3
Четверьг:
Привет!
Как правильно построить отношения с разрабом?
До этого имел дело только с готовыми движками, поэтому все вопросы с разрабами и дизайнерами сводились к доработке существующего скрипта, т.е. каркас как бы уже был, на него надо было только навешать свои плюшки, либо просто поменять что-то в уже готовом скрипте.

Сейчас встал вопрос разработки определенного веб сервиса с нуля.
Понятно, что начинать надо с ТЗ.

А вот дальше как?
1. Дизайн, как я понимаю, это последняя стадия, т.е. он вешается на уже готовый функционал.
А куда выводить результат работы, пока нет дизайна? Ведь страницы-то по сути нет.
Как это сделать так, чтобы потом дизайнер и верстальщик не переделывали все заново?
2. Никто не любит копаться в чужом коде. Написал программер код, а потом с ним что-то случилось и он пропал. Как продолжать работу, если кодер новый, а код старый?
3. Выставлять ли разрабам требования по языку кода? ПХП, Java? По версии языка?
4. Как понять, что код оптимален по быстродействию и алгоритму, по дублям страниц и тд? Если торомза будут из-за неоптимального кода, они ведь, будут лечить, что дело не в коде, а так и должно быть, это ограничения языка, хостинга и тд, и по-другому не сделать.
5. Кто кроме кодера, дизайнера и верстальщика учавствует в создании веб сервиса?
6. Стоит ли отдавать всю работу одной студии (человеку) или лучше разбивать по разным исполнителям? Мне кажется, что лучше разбивать.
7. Фрилансер или студия? Я склоняюсь в фрилансерам.

1. Чтобы этот вопрос отпал нужно искать нормального кодера, который прикрутит к системе адекватный шаблонизатор - проблема сама собой решится.

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

3. Выставлять, если это оправдано. Чтобы понять - нужно посмотреть плюсы и минусы технологий, проконсультироваться с кем-нибудь. Вы владелец сервиса, соответственно и все последующие проблемы сопровождения лягут на ваши плечи.

5. Проектировщик БД как минимум. Если финансы позволяют - проектировщик интерфейсов, тестировщик.

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

P.S. ТЗ - очень важная часть, прорабатывать нужно очень детально, до каждой мелочи. Бывали ситуации, что разработчики делали кое-что по своему усмотрению - эти мелочи рушили часть бизнес-процессов, решаемых ПО. После этого все ТЗшки на среднего уровня разработки - минимум 20-листовые портянки :)

Ч
На сайте с 16.12.2010
Offline
362
#4

А надо прописывать то, как именно должен работать код? Ведь, одно и то же можно реалиозовать по-разному.

Например: такие-то данные должны писаться в такую-то таблицу, метод сортировки должен быть такой-то. Или это лишнее? И смотреть надо на то что на выходе?

ПС: уже читаю хабру как правильно составить ТЗ, там касаются подобных вопросов.

dglstyle
На сайте с 24.03.2011
Offline
70
#5
Четверьг:
А надо прописывать то, как именно должен работать код? Ведь, одно и то же можно реалиозовать по-разному.
Например: такие-то данные должны писаться в такую-то таблицу, метод сортировки должен быть такой-то. Или это лишнее? И смотреть надо на то что на выходе?

ПС: уже читаю хабру как правильно составить ТЗ, там касаются подобных вопросов.

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

W
На сайте с 04.04.2006
Offline
276
#6

Собираюсь решать те же проблемы в скором времени.

Выборочные замечания:

1) Почему дизайн в конце? Всегда все проекты начинаю с ТЗ для себя, а потом изображения того, что хочу получить.

2) Пропущен важный этап - отбор разработчика. Если не правильно выберете, то ничего не поможет.

3) Весь код должен быть задокументирован, как в коде, так и отдельно по функционалу.

ТОП3 Яндекса за 1-2 дня - это реально. Без роботности.
Ч
На сайте с 16.12.2010
Offline
362
#7
Wadim:
1) Почему дизайн в конце? Всегда все проекты начинаю с ТЗ для себя, а потом изображения того, что хочу получить.

Ну фиг знает, мне кажется, диз идет от функционала, а не наоборот. ПОэтому сначала функционал, что и как будет на выходе, а потом уже оформление этой выходной инфы. Может, я не и не прав.

Wadim:
2) Пропущен важный этап - отбор разработчика. Если не правильно выберете, то ничего не поможет.

Да.

Но, по этому пункту, как я понимаю, никто советов не даст, только свои шишки и чужие отзывы/рекомендации.

Wadim:
3) Весь код должен быть задокументирован, как в коде, так и отдельно по функционалу.

Можно попродробнее про этот пункт? О чем конкертно речь?

L
На сайте с 07.12.2007
Offline
351
#8
Четверьг:
3. Выставлять ли разрабам требования по языку кода? ПХП, Java? По версии языка?

Если не будет проблемы найти хостинг, который будет всё это поддерживать, и программиста, который будет сопровождать это хозяйство.

Четверьг:
6. Стоит ли отдавать всю работу одной студии (человеку) или лучше разбивать по разным исполнителям? Мне кажется, что лучше разбивать.

Если разбивать по исполнителям - будет сложнее украсть вашу идею на этапе разработки. Но придётся ТЗ разбивать на относительно независимые друг от друга части. И кто будет делать процесс отладки "всего в сборе"?

Четверьг:
7. Фрилансер или студия? Я склоняюсь в фрилансерам.

Фрилансеры не любят работать по договору и получать по безналу.

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

W
На сайте с 04.04.2006
Offline
276
#9
Четверьг:
Ну фиг знает, мне кажется, диз идет от функционала, а не наоборот. ПОэтому сначала функционал, что и как будет на выходе, а потом уже оформление этой выходной инфы. Может, я не и не прав.

От проекта зависит, я же не знаю что вы делаете. Можно нарисовав дизайн предполагаемого проекта понять какой еще функционал нужен. Или какой лишний. В любом случае сначала пишется ТЗ, значит функционал запланирован и вторым этапом его логично нарисовать.

Четверьг:

Да.
Но, по этому пункту, как я понимаю, никто советов не даст, только свои шишки и чужие отзывы/рекомендации.

Ну почему, если нужно пишите в личку, могу скинуть тестовые задания здесь вроде и скачанные...сам их правда не проверял.

Я создавал на одном форуме программистов обсуждение с целью понять как отбирать программистов (ссылку дать не могу - форум висит). Но мой вывод примерно такой "Чтобы отобрать программиста нужен другой программист, который его будет тестировать". Это если по уму.

Четверьг:

Можно попродробнее про этот пункт? О чем конкертно речь?

Ну что такое документирование кода, я думаю, вам понятно. В интернете есть материалы (на хабре вроде видел обсуждение), как его правильно нужно документировать. Перед началом работы у программиста по минимуму надо образцы задокументированного кода смотреть.

Ну, а вторая часть это мое личное мнение, делал так для себя, могу и ошибаться. Программист пишет название функционала, например, "создание фильтров товара" а справа в таблице пишет имена файлов где реализован и описан данный функционал.

ishipilov
На сайте с 25.12.2011
Offline
101
#10

я разраб, могу ответить на ваши вопросы

1. Дизайн, как я понимаю, это последняя стадия, т.е. он вешается на уже готовый функционал.
А куда выводить результат работы, пока нет дизайна? Ведь страницы-то по сути нет.
Как это сделать так, чтобы потом дизайнер и верстальщик не переделывали все заново?

обычно когда нет дизайна, я все делаю на бутстрапе. Если нет дизайна можете сделать схематичный макет, что для бутстрапа более чем достаточно (я сейчас делаю проект, клиент мне как раз дал схематичный макет).

2. Никто не любит копаться в чужом коде. Написал программер код, а потом с ним что-то случилось и он пропал. Как продолжать работу, если кодер новый, а код старый?

Никто не любят, но работают...

3. Выставлять ли разрабам требования по языку кода? ПХП, Java? По версии языка?

Если технологии не так критичны, то рекомендую брать самые популярные: php, js/jquery, bootstrap и пр., последние стабильные версии.

4. Как понять, что код оптимален по быстродействию и алгоритму, по дублям страниц и тд? Если торомза будут из-за неоптимального кода, они ведь, будут лечить, что дело не в коде, а так и должно быть, это ограничения языка, хостинга и тд, и по-другому не сделать.

Любопытный вопрос :)

Тут, наверное, никак. Про "ограничения языка" это бред. Если тормоза появятся - переходить на более мощный сервер. Если даже после этого тормоза не исчезнут - менять кодера.

А вообще исходя из техзадания можно сразу сказать как долго будут загружаться странички.

5. Кто кроме кодера, дизайнера и верстальщика учавствует в создании веб сервиса?

сеошники, маркетологи, менеджеры и прочие любители освоить бюджет.

6. Стоит ли отдавать всю работу одной студии (человеку) или лучше разбивать по разным исполнителям? Мне кажется, что лучше разбивать.

дело вкуса и/или зависит от вашего времени и бюджета.

7. Фрилансер или студия? Я склоняюсь в фрилансерам.

хз, фрилансеры дешевле (не всегда), студии дают бумажки. Лажают и те и другие.

123 4

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий