- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Я сам учусь на специальности экономист-программист в экономическом ВУЗе(факультет прикладная информатика в экономике),и при составлении ТЗ говорил программисту на каком ЯПе это легче реализовать,объяснял почти каждый шаг,каждую функцию на сайте,как она должна быть реализована,алгоритм ее
Возможно эта ваша "осведомленность" и отталкивает... :)
WebJunior, это ирония?
Да специальность у меня такая,но на самом деле нас готовят на введении бизнеса в IT-сфере,незнаю почему,но в дипломе написано будет экономист-программист.
TF-Studio, с каждым программистом встречался лично, и имели неплохие работы,это не фрилансеры,а целые конторы,которые делаю вместо месяца полгода...
WebJunior, это ирония?
Нет. Это я "теоретизирую".
Просто психологически трудно приступить к работе с заказчиком, которому, возможно, придется обосновывать верность каждого шага (тз совсем до мелочей).
...ну и схалтурить нельзя... может избалованы они заказчиками которые не в состоянии проверить качество реализации.
Вот им и делают, а вас стороной обходят :)
WebJunior, многие программисты наоборот жалуются,что ТЗ не информативным бывает,поэтому я решил,что лучше так)
--MINAD--,
проблема пунктуальности программистов - как мне кажется не в самих программистах, а в так сказать "инфраструктуре" вокруг них, ну и опыте. Тупики, которые потом выражаются в отключенном электричестве, сломанных винчестерах и т.д. возникают, когда есть много задач и не понимаешь за что взяться и первая же крупная проблема цепляет другие.
По поводу оплаты - сервисы безопасных сделок помогают. Правда, частично, но уже лучше чем ничего.
Кроме того, если деньги вы заплатили (через СБС), то можете и требовать работы через системы контроля версий - так будете видеть, что работа идёт. При этом нужно ставить условие, что минимум, например, 3 коммита в день. Через некоторое время можно сказать, что вы - программер и понимаете, что некоторые коммиты сделаны "абы были", нужно устранить такое недоразумение.
Кроме того, ведите разработку в "гибком" стиле - я выбрал для себя Канбан-методику (через trello.com работаем) - ставится ограниченное количество тикетов, которые нужно реализовать (остальные вносятся на неосновную доску и я с ними работаю предварительно сам). Чем меньше тикетов в To Do - тем меньше отвлечения внимания и меньше "паники" у программиста.
В один момент одним программистом может исполнятся только один тикет, он его может передать на тестирование или вернуть назад в To Do, если что-то непонятно в реализации. После перенесения в Testing функционал проверяется уже не программистом и в комментарии карточки-тикета заносятся новые пожелания, сама карточка "переезжает" в To Do и ставится на нужное место в зависимости от приоритета. Это если появились новые нюансы или баги. Если же все ок - карточка переезжает в Done.
Раз в неделю оттестированный функционал выливается на продакшн (для нового проекта это не актуально, но через какой-то момент уже можно делать, не дожидаясь, когда все-все фичи будут реализованы).
Функционал постоянно наращивается и при этом вы делаете то, что нужно, а не то, что жестко прописано в ТЗ.
Ключевое, как по мне показать программисту, что вы - не враг и то, что вы программист - это наоборот плюс, в случае проблем можно находить общее решение. Также просите, чтобы если возникли какие-то тупики - не зависали, а писали об этом. Часто проблема быстро решается, по причине того, что у человека просто глаз замылился и сторонний взгляд быстро выводит из тупика.
Прикиньте сколько вы готовы платить в месяц и рассчитывайте на эту сумму, а не сумму за весь проект. В этом моменте возникают проблемы с тем, что при СБС нужен договор в котором желательно внести ТЗ, а гибкие методологии они частично расходятся с жестким ТЗ.
Поэтому, наверное, придется описать саму схему работы и то как она должна оцениваться.
Если работать по жесткому ТЗ, то программист должен проставить конкретные даты для всех этапов и миниэтапов работы - это хоть как-то подстёгивает, заодно такой план можно внести в договор при заключении сделки в СБС.
В общем, вот такой какой-то поток мыслей, может какие-то из них будут полезны вам, если будут вопросы - задавайте, по возможности попробую ответить :)
p.s. Сейчас у меня по вышеописанной схеме уже работа не через СБС идёт, взаимное доверие наработано.