Comments 109
Первым делом разработали API для фотографий.
Мы отказались от КЛАДРА в пользу ФИАСА
Наконец добрались до робота импорта XML-фидов.
Ребята, на самом деле, не умаляя важности хорошей архитектуры с точки зрения легкости сопровождения, но для коммерческого успеха сайта она находится далеко не на первом месте. Я не знаю, каким был руководителем тот босс, но в одном он прав. На первом месте — SEO. Совсем недалеко за ним идут быстродействие и стабильность сайта, поддержка мобильных устройств, простота и понятность поиска, фильтрации. Всё остальное, различные API для интеграции, документация для разработчиков и тем более для пользователей, это не важно для сайта, продающего товары/услуги. Если сайт продает ИТ-сервисы, то да, ему нужна документация для разработчиков. Документация пользователям обычно не нужна от слова «вообще». Потому что если какие-то действия на сайте портала не интуитивно понятны, а требуют прочтения документации, 99% пользователей его закроют и пойдут на другой портал, а не будут разбираться.
По моему нужен был нормальный маркетолог, а не заштыриваться в SEO.
Конечно, СЕО важно, но надо не зацикливаться на нем. Толку иметь сайт в топе выдачи, если при переходе на него люди не могут удовлетворить свои потребности. Они уйдут и больше не вернутся.
UFO just landed and posted this here
Вы верно говорите, но по статье ведь нет никаких предпосылок предполагать, что люди не могут удовлетворить свои потребности. В конце-концов, если сайт несколько лет подряд был «миллионником», значит, свои задачи он выполнял.
Потребности меняются.
В 2000-х годах например крупный сайт BN.ru размещал строчки с предложениями (без фото, без описаний, просто дублировал журнал Бюллетень Недвижимости) и кучу баннеров. Тогда вообще все сайты по недвижимости пестрели баннерами, и монетизация шла в основном через них. Фоток квартир было мало потому что на смартфонах ещё не было камер со сносным качеством.
Затем появились новые сайты с фотками, описаниями, удобными поиском и картой, а BN попал в западню: даже после ввода более подробных страниц объекта, большинство агентств всё равно слали им данные в привычном виде (только строчки).
Плюс само пользовательское поведение стало меняться. Если раньше для решения проблемы в основном шли в Яндекс, то теперь недвижимость ищется через сайты, которые на слуху (тот же Авито). Зоопарк порталов стал сжиматься, и такое идёт не только в сфере недвижимости, а вообще во всех сферах. На каждом направлении появляется 2-3 крупных портала-агрегатора, они тянут на себя значительный трафик, а остальным приходится выживать.
Другое дело, что часть порталов из прошлого и сейчас хорошо себя чувствует, и если бы владельцы этого портала вместо сео занимались бы удобством работы с ним в новых реалиях, а разработчики вместо тайного переписывания движка занимались бы обеспечением этого удобства — глядишь не было бы схлопывания посещаемости в 1000 раз.
В 2000-х годах например крупный сайт BN.ru размещал строчки с предложениями (без фото, без описаний, просто дублировал журнал Бюллетень Недвижимости) и кучу баннеров. Тогда вообще все сайты по недвижимости пестрели баннерами, и монетизация шла в основном через них. Фоток квартир было мало потому что на смартфонах ещё не было камер со сносным качеством.
Затем появились новые сайты с фотками, описаниями, удобными поиском и картой, а BN попал в западню: даже после ввода более подробных страниц объекта, большинство агентств всё равно слали им данные в привычном виде (только строчки).
Плюс само пользовательское поведение стало меняться. Если раньше для решения проблемы в основном шли в Яндекс, то теперь недвижимость ищется через сайты, которые на слуху (тот же Авито). Зоопарк порталов стал сжиматься, и такое идёт не только в сфере недвижимости, а вообще во всех сферах. На каждом направлении появляется 2-3 крупных портала-агрегатора, они тянут на себя значительный трафик, а остальным приходится выживать.
Другое дело, что часть порталов из прошлого и сейчас хорошо себя чувствует, и если бы владельцы этого портала вместо сео занимались бы удобством работы с ним в новых реалиях, а разработчики вместо тайного переписывания движка занимались бы обеспечением этого удобства — глядишь не было бы схлопывания посещаемости в 1000 раз.
Ну да, когда куча агентов под видом физ. лиц сдают-снимают-продают-покупают, то такой бизнес загнется в какой то момент времени. Хотя судя по наличию объявлений «русская семья снимет квартиру в вашем районе» кто то еще ведется на это.
Я бы на вашем месте сделал бы другой главный вывод: надо смотреть не только на то, как ты делаешь, но и на то, что ты делаешь, для кого и какие перспективы.
Я бы на вашем месте сделал бы другой главный вывод: надо смотреть не только на то, как ты делаешь, но и на то, что ты делаешь, для кого и какие перспективы.
Я правильно понял — вместо того что бы делать фичи, которые могли быть жизненно необходимы в проекте, два разработчика в течении года тайком от руководства переписывало проект?
Я наверное выскажу очевидные вещи — всем пользователям все равно на чем написан проект, как он работает внутри, используется ли там perl образца 2001 года или новомодный фреймворк. Главное что бы сервис быстро, интуитивно и удобно выполнял задачи пользователей.
Тут встает такой вопрос — а пробовали ли Вы донести до руководства, что перенос картинок из БД ускорит загрузку сайта, тем самым повысив удобство пользователей? И например можно потратить неделю и переписать только эту часть, не трогая другие костыли.
Я наверное выскажу очевидные вещи — всем пользователям все равно на чем написан проект, как он работает внутри, используется ли там perl образца 2001 года или новомодный фреймворк. Главное что бы сервис быстро, интуитивно и удобно выполнял задачи пользователей.
Тут встает такой вопрос — а пробовали ли Вы донести до руководства, что перенос картинок из БД ускорит загрузку сайта, тем самым повысив удобство пользователей? И например можно потратить неделю и переписать только эту часть, не трогая другие костыли.
Насколько я понял, профит таки был: страницы стали отдаваться быстрее, парсинг XML стал занимать меньше времени.
Другое дело, что дефицитный ресурс (рабочее время разработчиков) возможно использовалось не для того, что действительно приоритетно. Какой смысл в удобном личном кабинете например, если твои объекты по недвижимости с каждым годом смотрит всё меньше посетителей? Вероятен сценарий, что разработчики вместо оптимизации того, что есть, поигрались с интересными им технологиями и приложили руку к падению проекта на дно.
Но возможно это просто естественный процесс. С появлением и ростом Авито, ЦИАНа (вот они кстати молодцы, из чего-то абсолютно неюзабельного они сделали удобный и популярный портал) и Яндекс Недвижимости многие очень популярные порталы из прошлого стали неактуальны. Некоторые ещё держатся на старых технологиях (EMLS например), но это скорее исключение. Так что возможно с такими ресурсами просто объективно было нельзя ничего сделать, и жизненный цикл портала закончился сам по себе.
Другое дело, что дефицитный ресурс (рабочее время разработчиков) возможно использовалось не для того, что действительно приоритетно. Какой смысл в удобном личном кабинете например, если твои объекты по недвижимости с каждым годом смотрит всё меньше посетителей? Вероятен сценарий, что разработчики вместо оптимизации того, что есть, поигрались с интересными им технологиями и приложили руку к падению проекта на дно.
Но возможно это просто естественный процесс. С появлением и ростом Авито, ЦИАНа (вот они кстати молодцы, из чего-то абсолютно неюзабельного они сделали удобный и популярный портал) и Яндекс Недвижимости многие очень популярные порталы из прошлого стали неактуальны. Некоторые ещё держатся на старых технологиях (EMLS например), но это скорее исключение. Так что возможно с такими ресурсами просто объективно было нельзя ничего сделать, и жизненный цикл портала закончился сам по себе.
Жизненно.
Ошибка босса в том что он вас не контролировал, и вы с ним разговаривали на разных языках.
Кто-то в компании должен объединять все отделы в единый организм. Если не босс, то какой то менеджер, который разбирается и в том что вы творите и в сео и текстах и тд.
Иначе получается лебедь, рак и щука.
Если кто-то не дирижирует этим оркестром, то провал — вопрос только времени. Если каждый в оркестре будет думать что он сам отдельно от дирижера сейчас сыграет супер развязочку, пусть не по нотам, но зато от души, от всего сердца, то в результате получится какофония. Вы же сами признаете что было много сео задач, но время вы тратили на переписывание как в вашем понимании должно быть лучше.
Успех компании это слаженная работа всего организма, каждый орган должен быть здоров и работать поддерживая всех остальных. Тогда на выходе получается лучший продукт, а не продукт где лучший дизайн, но плохое сео, или идеальный движок, но опять же низкое сео и тд.
Ошибка босса в том что он вас не контролировал, и вы с ним разговаривали на разных языках.
Кто-то в компании должен объединять все отделы в единый организм. Если не босс, то какой то менеджер, который разбирается и в том что вы творите и в сео и текстах и тд.
Иначе получается лебедь, рак и щука.
Если кто-то не дирижирует этим оркестром, то провал — вопрос только времени. Если каждый в оркестре будет думать что он сам отдельно от дирижера сейчас сыграет супер развязочку, пусть не по нотам, но зато от души, от всего сердца, то в результате получится какофония. Вы же сами признаете что было много сео задач, но время вы тратили на переписывание как в вашем понимании должно быть лучше.
Успех компании это слаженная работа всего организма, каждый орган должен быть здоров и работать поддерживая всех остальных. Тогда на выходе получается лучший продукт, а не продукт где лучший дизайн, но плохое сео, или идеальный движок, но опять же низкое сео и тд.
UFO just landed and posted this here
На прошлой работе пошли путем хранения БД, потом столкнулись с тем, что такие размеры SSD для базы очень и очень дорогие. Просто для файлов есть специальные распределенные файловые системы, а для связанных данных есть СУБД. Когда файлов не так можно — быстрее и надежней использовать базу, а вот когда размер зашкаливает за сотни терабайт — тут уже нужно пользоваться специализированными инструментами.
Так файлы можно и на HDD хранить, MS SQL Server так умеет же.
Не верьте маркетологам из Microsoft. Файл есть файл: туп, понятен и отказо-устойчив.
При чем тут маркетологи?
Потому что всунули в БД функционал который паршиво работает, под видом крутой фичи. Причем собезьянничали Oracle.
И сами крайне редко используют эту фишку в своих продуктах.
Причем казалось бы в продукте как шарепоинт или проджект, это решение напрашивается, однако нет. Сменилось уже 3 поколения платформ, а использование filestream до сих пор не включили в рекомендуемый набор по развертыванию.
Хотя шарепоинт это и есть файлопомойка++ (утрирую конечно, но у многих именно так)
И сами крайне редко используют эту фишку в своих продуктах.
Причем казалось бы в продукте как шарепоинт или проджект, это решение напрашивается, однако нет. Сменилось уже 3 поколения платформ, а использование filestream до сих пор не включили в рекомендуемый набор по развертыванию.
Хотя шарепоинт это и есть файлопомойка++ (утрирую конечно, но у многих именно так)
Шарик и SQL Server делают разные команды. Не виду каким образом решения принятые разработчиками шарика говорят что-то о качестве фич SQL Server. Это во-первых.
А во-вторых, надо плясать не от крутости фишек, а от задачи. И если есть задача хранить файлы на HDD, а основную часть данных — на SSD, то в SQL Server есть простое решение. Которое куда проще чем альтернативы с раздельным хранением файлов и их описаний.
Вот если файлов становится так много что их надо начинать хранить распределенно — это уже другая задача, и SQL Server ее не решает. Но тут-то обсуждается совсем не такая ситуация.
А во-вторых, надо плясать не от крутости фишек, а от задачи. И если есть задача хранить файлы на HDD, а основную часть данных — на SSD, то в SQL Server есть простое решение. Которое куда проще чем альтернативы с раздельным хранением файлов и их описаний.
Вот если файлов становится так много что их надо начинать хранить распределенно — это уже другая задача, и SQL Server ее не решает. Но тут-то обсуждается совсем не такая ситуация.
95% данных в шарепоинте это Word, Excel, PDF.
И задачи собственно те-же. Положить файл в хранилище, обеспечить его индексацию, совместную работу с ним, права доступа и относительно компактное хранение.
Что же до команд, то это 2 команды которые работают над флагманскими продуктами для бизнеса.
И в этом разрезе видно что команда шарепоинта просто забила, а команда сиквела согласилась.
И общепринятая практика на сегодняшний момент хранить всякий «стафф» в файловой системе, обеспечивая индексацию средствами шарепоинта, а права доступа средствами файловой системы. Серьезные же документы хранятся в базе данных, где обеспечена версионность, ролевая модель IRM и всякие другие плюшки.
И задачи собственно те-же. Положить файл в хранилище, обеспечить его индексацию, совместную работу с ним, права доступа и относительно компактное хранение.
Что же до команд, то это 2 команды которые работают над флагманскими продуктами для бизнеса.
И в этом разрезе видно что команда шарепоинта просто забила, а команда сиквела согласилась.
И общепринятая практика на сегодняшний момент хранить всякий «стафф» в файловой системе, обеспечивая индексацию средствами шарепоинта, а права доступа средствами файловой системы. Серьезные же документы хранятся в базе данных, где обеспечена версионность, ролевая модель IRM и всякие другие плюшки.
Вот только эта общепринятая практика не имеет ничего общего с обсуждаемой тут проблемой: такое решение растет из совершенно других задач.
или тогда уж не хранить размеры, а сделать ресайз on-fly и добавить слой кэширующего прокси.
Разница тут вот в чем. Чтобы отдать картинку посетителю, вам нужно:
1. Сервер получает запрос.
2. Передает его на бэк.
3. Бэк лезет в базу и делает там выборку.
4. Бэк передает извлеченную картинку серверу.
5. Сервер отдает её посетителю.
Если же хранить на файловой системе, то все ограничивается пунктами 1 и 5.
На сайтах с небольшой нагрузкой разница не очень заметна. Но вот когда база разрастается на гигабайты и сайт начинают посещать уже не полтора пользователя в день, все становится очень грустно.
1. Сервер получает запрос.
2. Передает его на бэк.
3. Бэк лезет в базу и делает там выборку.
4. Бэк передает извлеченную картинку серверу.
5. Сервер отдает её посетителю.
Если же хранить на файловой системе, то все ограничивается пунктами 1 и 5.
На сайтах с небольшой нагрузкой разница не очень заметна. Но вот когда база разрастается на гигабайты и сайт начинают посещать уже не полтора пользователя в день, все становится очень грустно.
Если же хранить на файловой системе, то все ограничивается пунктами 1 и 5.
Это если у вас картинки лежат прямо на сервере, выставленном во внешний мир по HTTP.
А где им лежать? CDN?
Могут лежать и на другом сервере, но и в этом случае хранение картинок в базе добавляет заметный оверхед без получения особого профита от этого. И, по моему мнению, этого лучше избегать и использовать специализированные решения, заточенные на работу с файлами/объектами.
Могут лежать и на другом сервере, но и в этом случае хранение картинок в базе добавляет заметный оверхед без получения особого профита от этого. И, по моему мнению, этого лучше избегать и использовать специализированные решения, заточенные на работу с файлами/объектами.
CDN. S3/GCP/ABS. Просто другой сервер из соображений безопасности.
В случае с CDN делать вообще ничего не надо. Просто заменяем ссылки на картинки в коде.
Про S3/GCP и прочее —
не?
С другого сервера аналогично, s3-compatible например (minio etc), или даже монтировать через nfs.
Про S3/GCP и прочее —
proxy_pass http://my_bucket.s3.amazonaws.com/...не?
С другого сервера аналогично, s3-compatible например (minio etc), или даже монтировать через nfs.
В случае с CDN делать вообще ничего не надо.
Если у вас CDN как услуга, то да.
Про S3/GCP и прочее
Если у вас открыт доступ к хранилищу по HTTP.
даже монтировать через nfs.
Это если между ними есть такая сеть.
И согласитесь, да, что кроме случая с CDN, это уже далеко не "Сервер получает запрос — Сервер отдает её посетителю."
> Если у вас открыт доступ к хранилищу по HTTP.
Ну например — github.com/bsc-s2/lua-resty-s3-client
Lua в nginx очень быстрое.
А еще можно наколхозить горячий in memory кэш на сервере.
> Это если между ними есть такая сеть.
И что же мешает поднять приватную подсеть?
> И согласитесь, да, что кроме случая с CDN, это уже далеко не «Сервер получает запрос — Сервер отдает её посетителю.»
Ну да, кое-какие телодвижения для настройки нужно сделать.
Но это таки не тот адок, когда для выдергивания картинки, скажем, 1х1 или 5000х5000 нужно отдавать запрос бэку, ждать пока он там прожует и пошуршит по базе и отдаст результат, и только уже потом его можно отдавать посетителю.
Ну например — github.com/bsc-s2/lua-resty-s3-client
Lua в nginx очень быстрое.
А еще можно наколхозить горячий in memory кэш на сервере.
> Это если между ними есть такая сеть.
И что же мешает поднять приватную подсеть?
> И согласитесь, да, что кроме случая с CDN, это уже далеко не «Сервер получает запрос — Сервер отдает её посетителю.»
Ну да, кое-какие телодвижения для настройки нужно сделать.
Но это таки не тот адок, когда для выдергивания картинки, скажем, 1х1 или 5000х5000 нужно отдавать запрос бэку, ждать пока он там прожует и пошуршит по базе и отдаст результат, и только уже потом его можно отдавать посетителю.
Ну например — github.com/bsc-s2/lua-resty-s3-client
Это все равно больше не сингл-хоп.
И что же мешает поднять приватную подсеть?
Разные ситуации бывают.
Ну да, кое-какие телодвижения для настройки нужно сделать.
Здесь вопрос не в том, какие телодвижения надо сделать для настройки, а в том, где случается ботлнек в производительности.
Но это таки не тот адок
В обмен на адок вида "как бы нам обеспечить консистентность хранилища в БД и на файловой системе". А еще ведь перед бэком, который лазит за картинкой в БД, можно поставить кэш...
> Здесь вопрос не в том, какие телодвижения надо сделать для настройки, а в том, где случается ботлнек в производительности.
Вот по нашему опыту, ботлнек как раз именно в «бэк лезет в базу за картинками».
> В обмен на адок вида «как бы нам обеспечить консистентность хранилища в БД и на файловой системе». А еще ведь перед бэком, который лазит за картинкой в БД, можно поставить кэш…
И в чем проблема с консистентностью?
С базой, кроме всего прочего, я еще вижу некоторую проблему в кластеризации и процессе бэкапа базы таких объемов.
Вот по нашему опыту, ботлнек как раз именно в «бэк лезет в базу за картинками».
> В обмен на адок вида «как бы нам обеспечить консистентность хранилища в БД и на файловой системе». А еще ведь перед бэком, который лазит за картинкой в БД, можно поставить кэш…
И в чем проблема с консистентностью?
С базой, кроме всего прочего, я еще вижу некоторую проблему в кластеризации и процессе бэкапа базы таких объемов.
Вот по нашему опыту, ботлнек как раз именно в «бэк лезет в базу за картинками».
У каждого своя ситуация.
И в чем проблема с консистентностью?
Каждая операция записи, связанная с картиной — распределенная транзакция.
С базой, кроме всего прочего, я еще вижу некоторую проблему в кластеризации и процессе бэкапа базы таких объемов.
… а проблем с бэкапом файлового хранилища такого объема вы не видите?
> Каждая операция записи, связанная с картиной — распределенная транзакция.
Это решаемая и не запредельной сложности проблема. К тому же никак не влияющая на посетителей.
> … а проблем с бэкапом файлового хранилища такого объема вы не видите?
Эти проблемы решается сильно проще. Инкрементальные бэкапы, дедупликация, распределенные файловые системы — вот это вот все.
Я говорил, есть же специальные решения, придуманные и отточенные для работы с файлами. База данных к этому относится очень с натяжкой.
Это решаемая и не запредельной сложности проблема. К тому же никак не влияющая на посетителей.
> … а проблем с бэкапом файлового хранилища такого объема вы не видите?
Эти проблемы решается сильно проще. Инкрементальные бэкапы, дедупликация, распределенные файловые системы — вот это вот все.
Я говорил, есть же специальные решения, придуманные и отточенные для работы с файлами. База данных к этому относится очень с натяжкой.
Это решаемая и не запредельной сложности проблема. К тому же никак не влияющая на посетителей.
… пока она не ломается.
Впрочем, мой пойнт был не в этом. Мой пойнт был в том, что ваше "Если же хранить на файловой системе, то все ограничивается пунктами 1 и 5" верно только в примитивном случае.
Ну вот в большинстве случаев (опять таки по нашему опыту) как раз такой подход (т.е. CDN и подобное, с отдачей картинок сразу по http) и оказывается самым эффективным.
UFO just landed and posted this here
UFO just landed and posted this here
А мне не ясно, почему у вас что-то тормозило из-за картинок в базе. Сколько я не измерял — всегда разница была незначительной между хранением в БД и в файловой системе. Поэтому предпочитал и предпочитаю хранить в БД, ибо целостность.
Целостность в БД в конечном итоге образуется через целостность файловой системы. И если используете картинки как обычно это делают — раз загрузили и только читаете — преимуществ у СУБД нет. При конкурентной записи, постоянном изменении одних и тех же картинок — еще какой-то смысл есть.
А вот кэши СУБД/быстрые диски SSD, которые были бы полезны для запросов без картинок — забиваются тем, с чем легко справляется файловая система напрямую без БД с обычных дисков HDD
UFO just landed and posted this here
История о том, что перестановка кроватей в борделе ни привела к росту его прибыли.
Конечно обидно, что труд нескольких лет остался не востребованным, но с другой стороны лично вы прокачали скилы и этот ваш опыт сам по себе ценность. Теперь можете рассчитывать на трудоустройство в более интересном и ИТ -ориентированном месте, где успешно будете применять эти навыки.
Конечно обидно, что труд нескольких лет остался не востребованным, но с другой стороны лично вы прокачали скилы и этот ваш опыт сам по себе ценность. Теперь можете рассчитывать на трудоустройство в более интересном и ИТ -ориентированном месте, где успешно будете применять эти навыки.
Я пришел на эту работу в 2014 году, простым junior .net.
На втором году работы, мой руководитель ушел с проекта. И я остался один на один с этой древней махиной, в которой было от силы 3% моего кода.
Если руководитель не стал ни чего предпринимать и просто слился — тут или он сам по себе такого склада (инфантильный с позиции тех. эксперта), или попросту понимал что уже ни чего нельзя было исправить (руководство не принимало информацию к сведению). В любом случае весь рассказ больше о всё об одном — ошибке управления и адаптации на рынке, технические аспекты могли иметь место быть, но как уже упомянули ранее — их роль была далеко не основополагающей.
Если та нить между сотрудниками, которая удерживает бизнес на плаву, порвана, то ваш продукт непременно пойдет ко дну.
Вероятен сценарий, что каждый со своей колокольни думает что знает рынок и свой продукт, но на самом деле не видит целостной картины.
Спасибо за еще одно подтверждение того, что стоит избегать разработчиков с парой лет опыта. Практически всегда повторяется одна и та же история. я называю это проблемой «самого важного человека в команде». Из этой ситуации нужно сделать один важный вывод: код не имеет большого значения. вангую что будь все написано на вордпрессе, результат был бы такой же. учитесь на своей ошибке, а не вините своего сео.
Во-первых никто не винит нашего СЕО. К слову у нас сменилось 4-5 СЕО за это время и каждый переделывал все после предшественников. Кстати последний СЕО делал и делает правильные вещи.
Я старался никогда не обвинять. Мы тоже где-то действовали в своих интересах, но на это у нас были причины.
Про избегание начинающих разрабов… Попахивает дискриминацией по признаку отработанных лет. Каждый джуниор должен иметь возможность получить опыт, чтобы стать кем то большим.
Эта компания оказалась одной из таких, за что ей надо отдать должное.
Я старался никогда не обвинять. Мы тоже где-то действовали в своих интересах, но на это у нас были причины.
Про избегание начинающих разрабов… Попахивает дискриминацией по признаку отработанных лет. Каждый джуниор должен иметь возможность получить опыт, чтобы стать кем то большим.
Эта компания оказалась одной из таких, за что ей надо отдать должное.
вы путаете seo и сео. странно что вы гтворите о том, что попахивает дискриминацией. Я говорил об этом прямо, чем больше человек имеет опыта, тем более хорошо он осознает происэодящее. Если ваща цель была поучиться за счет компании, все отлично, я ни в коем случае не осуждаю, но если ваша цель была сделать продукт который победит конкурентов, то это, увы, не ваша проблема, и идеалтность кода на нее влияет мало. по поводу обвинения, по-моему очевидно, что это статья про обиду. если вы хотите развиваться — расслабьтесь, это не ваше время. кмк это и есть главная проблема маленького опыта — ты думаешь, что каждый проект — место для геройства и обижаешься, если тебя не оценили. на самом деле важнее просто делать хорошо ту работу, которую от тебя ждут.
Пардон, с утра попутал сео/seo. Насчет обиды это правда. Действительно, очень обидно что так все вышло. Мы старались, боролись, но иногда этого мало(
поддержу. со временем приходит понимание, что проекты разные. есть те, где надо сделать без дополнительного энтузиазма, но шустро, а есть и места, где нужно исследование и много личное инициативы.
что стоит избегать разработчиков с парой лет опыта
Избегайте, ваше право. Вот только опытных, как показывает практика, с каждым годом всё меньше, а запросы у них всё выше… :)
Вполне может быть, что печальный итог никак не связан с деятельностью ни директора, ни автора.
Мир меняется. Глобализируется. Некоторые услуги просто пропадают (уменьшаются на порядки), другие появляются. Остаются только крупные игроки, которым принадлежит большая часть глобального рынка. Остальные делят крохи.
Мир меняется. Глобализируется. Некоторые услуги просто пропадают (уменьшаются на порядки), другие появляются. Остаются только крупные игроки, которым принадлежит большая часть глобального рынка. Остальные делят крохи.
Это просто классика. Когда технологический проект делает человек (руководитель), далекий от технологий, то в итоге получается такое. Сам регулярно с таким сталкивался, даже прямо сейчас есть такой проект. Владелец проекта при выборе технологической платформы слушает друзей-предпринимателей, а не программистов и devops.
Всегда попадалось, почему-то, такое же начальство, которое всё делает против ИТ-отдела. Наверное это правда жизни: управлять и быть тупым)
При наличии кучи всего — начиная от БН/БСН/ЕМЛС до Авито обращаться к кому-то новому… не уверен что оно может выстрелить и жить долго (по моему мнению бизнес недвижимости с одной стороны подорвало авито, а с другой реклама «агентства наживаются на вас», от чего агентствам стало хуже (и лучше маклерам, которые вернулись из 90х со всеми своими приёмами и киданиями клиентов, но зато у клиента иллюзия личного менеджера и почему-то безопасности, да ещё появились «информагентства», просто берущие деньги).
У Вас много внимания в статье, и наверное в работе, уделено внутренней кухне сайта.
Но сайт умер, вероятно, по другим причинам — его вытеснили в естественном отборе другие сайты, предлагающие подобную информацию в более удобном виде.
Не увидел в обзоре сравнения вашего сайта с конкурентами на рынке, набора ключевых показателей этого сравнения, и попыток их улучшить.
копание внутри сайта без оглядки на рынок — позиция страуса, который копает червячка в песке, оставив жопу беззащитной
Но сайт умер, вероятно, по другим причинам — его вытеснили в естественном отборе другие сайты, предлагающие подобную информацию в более удобном виде.
Не увидел в обзоре сравнения вашего сайта с конкурентами на рынке, набора ключевых показателей этого сравнения, и попыток их улучшить.
копание внутри сайта без оглядки на рынок — позиция страуса, который копает червячка в песке, оставив жопу беззащитной
«Так никто не ищет, это низкочастотный запрос, я уверен»
до боли знакомо)) три мульона доводов, сценариев рассказываешь, а он — не, у нас же специфика)) а ты ему опять — да никто не ищет товар по коду в официальном каталоге производителя, потому что никто его не знает, ищут по модели и тому, что увидели на бумажке, перебирая все варианты. А он тебе — нифига, это все неправильные коды))
Потому что такие слова нужно подтверждать данными из аналитики, а то выглядит что программист просто решил поумничать.
> да никто не ищет товар по коду в официальном каталоге производителя, потому что никто его не знает, ищут по модели и тому, что увидели на бумажке
Не факт. Я например когда ищу запчасть к машине вбиваю в гугл её partnumber найденный под картинкой, скажем, hondapartsnow и гугл выкидывает мне список конкретных продавцов (в моем регионе). На порядки удобнее и быстрее, чем попытка сформировать запрос «вон ту хреновину от коробки передач на такой то пепелац».
Не факт. Я например когда ищу запчасть к машине вбиваю в гугл её partnumber найденный под картинкой, скажем, hondapartsnow и гугл выкидывает мне список конкретных продавцов (в моем регионе). На порядки удобнее и быстрее, чем попытка сформировать запрос «вон ту хреновину от коробки передач на такой то пепелац».
UFO just landed and posted this here
Вот есть такой предприниматель — Олег Тиньков. К нему можно относиться по разному. Отрицательно, положительно или просто равнодушно. Но то что он довольно талантливый и успешный бизнесмен сделавший себя сам наверное никто спорить не будет.
В одном из своих интервью он дал дельный совет как найти себя в бизнесе. Этот совет просто до идиотизма простой.
Точную цитату сейчас лень искать. Но все что он тогда наговорил можно вынести тезисом в одно слово: улучшайте.
Хамят продавцы в магазине у дома? Откройте по соседству такой же, только с вежливым и внимательным персоналом.
Роскосмос дорого запускает спутники? Придумайте технологию возврата ступеней и снижайте стоимость пуска с каждым запуском (уже).
В общем щупайте слабые места конкурентов и аккуратно туда давите.
В связи с этим я не понимаю автора статьи. Если вы, автор, со своим техническим напарником были настолько подкованы во всем бизнес-процессе фирмы и постоянно фейс-палмили от нелогичных решений руководителя, что вам мешало запустить свой сервис с домами и риелторами?
Запустили бы и показали как надо. А дядю бывшего начальника на вертушку охранником посадить.
В одном из своих интервью он дал дельный совет как найти себя в бизнесе. Этот совет просто до идиотизма простой.
Точную цитату сейчас лень искать. Но все что он тогда наговорил можно вынести тезисом в одно слово: улучшайте.
Хамят продавцы в магазине у дома? Откройте по соседству такой же, только с вежливым и внимательным персоналом.
Роскосмос дорого запускает спутники? Придумайте технологию возврата ступеней и снижайте стоимость пуска с каждым запуском (уже).
В общем щупайте слабые места конкурентов и аккуратно туда давите.
В связи с этим я не понимаю автора статьи. Если вы, автор, со своим техническим напарником были настолько подкованы во всем бизнес-процессе фирмы и постоянно фейс-палмили от нелогичных решений руководителя, что вам мешало запустить свой сервис с домами и риелторами?
Запустили бы и показали как надо. А дядю бывшего начальника на вертушку охранником посадить.
Зрите в корень. На данный момент именно этим мы занимаемся.
Улучшая, можно во-первых провалиться, т.к. зачастую лучше — дороже (или просто позже — дороже), а ещё можно не улучшить (как тот же Тиньков со страховой, который не смог предложить сервис даже на уровне конкурентов). Поэтому не магазин надо открывать, а делать хорошо что умеешь.
> Запустили бы и показали как надо
«Станьте ёжиками». Это же так просто и не требует вложений.
> Запустили бы и показали как надо
«Станьте ёжиками». Это же так просто и не требует вложений.
Улучшая, можно во-первых провалиться
Можно. Но как показала практика вперед вырываются только те кто постоянно находятся в развитии и поиске нового. Стагнация это один шаг до смерти любого дела (что мы и видим на примере данной статьи).
как тот же Тиньков со страховой, который не смог предложить сервис даже на уровне конкурентов
Подробности не знаю. Возможно это была его ошибка. Но как говорится не ошибается тот кто ничего не делает. И не стоит забывать, что Тиньков начинал как фарцовщик одежды, а на данный момент является долларовым миллиардером и владельцем банка. Прошел бы он этот путь, если бы являлся любителем стабильности и стагнации? Общий знаменатель его успешности более чем впечатляет.
«Станьте ёжиками». Это же так просто и не требует вложений.
Любое дело требует вложений.
Даже для того чтобы выиграть в лотерее нужно купить билет.
Адекватному человеку это изначально понятно и не требует никакого скудоумного обстебывания с неуместным сарказмом.
UFO just landed and posted this here
В действительности, я начал полностью переписывать систему практически с 0. Пришлось это делать тайно от руководства.
Не надо так делать.
Я искренне уважаю стремление автора вытянуть проект, его полную погруженность в работу и неиссякаемый энтузиазм. Но в тайне переписывать систему — это, я считаю, ошибка.
Разработчик не должен думать за бизнес и принимать решение за бизнес. Да, он может высказать свое мнение, предоставить свою экспертизу, выразить сомнение, проявить инициативу. Но без одобрения менеджмента делать крупный кусок работы — за это никто спасибо не скажет. Более того, это не очень-то и этично. Это как сказать прямым текстом: «Товарищ менеджер, ты сам не понимаешь, что ты делаешь. Поэтому я буду принимать решения за тебя, с тобой не посоветовавшись». Не надо решать за менеджмент, что делать.
К тому же, из текста для меня совсем не очевидно, почему проект провалился. Может, при текущем маркетинге, дизайне и фичах, даже если бы все летало, проект бы это не спасло.
Почему не надо?
Все-таки мы переписывали скорее для себя и будущих разработчиков, чтобы нам же было легче модернизировать и поддерживать продукт дальше, другими сотрудниками. Простые задачи больше не занимали много времени.
И эту задачу мы выполнили. Это был фундамент на будущее, которое мб когда-нибудь там и наступит.
Все-таки мы переписывали скорее для себя и будущих разработчиков, чтобы нам же было легче модернизировать и поддерживать продукт дальше, другими сотрудниками. Простые задачи больше не занимали много времени.
И эту задачу мы выполнили. Это был фундамент на будущее, которое мб когда-нибудь там и наступит.
А сколько процентов от рабочего времени вы тратили на переписывание? Насколько переписывание тормозило внедрение задач от руководства?
Мне это немного напомнило известную притчу про Васю, который наговнокодил и выпустил свой продукт на рынок быстро, и Петю, который долго вылизывал свой код, но закончил уже тогда, когда его продукт перестал быть актуальным.
Рефакторинг — это конечно хорошо, но если проект умирает, то может вместо закладывания фундамента на будущее лучше делать что-то другое?
Мне это немного напомнило известную притчу про Васю, который наговнокодил и выпустил свой продукт на рынок быстро, и Петю, который долго вылизывал свой код, но закончил уже тогда, когда его продукт перестал быть актуальным.
Рефакторинг — это конечно хорошо, но если проект умирает, то может вместо закладывания фундамента на будущее лучше делать что-то другое?
Почему не надо?
Потому что это не нормальные деловые отношения. Не надо брать на себя чужие зоны ответственности. Если руководство забраковало идею, нужно принять это решение. Не надо решать за других людей. Да, возможно, это неправильное решение. Но делать «благую работу» вопреки ему — это неправильно.
В командах приходится работать с большим количеством людей. Многие из которых не всегда принимают корректные решения. Везде всегда кажется, что кто-то что-то решил не так. Но нужно с этим жить, а не делать по своему. Максимум, что можно сделать — это выразить свое мнение. Или сменить работу. Но игнорировать чужие решения в их зоне ответственности — это не тру.
Далее, это просто неблагодарная работа. Премию за это вряд ли выпишут. Более того, если это всплывет, руководство вообще может отреагировать весьма негативно. Потому что в их глазах вы делаете не то, что должны.
Ну, и конечно, такая деятельность — она вызывает большое чувство обиды и неудовлетворенности. Если пытаться сделать все что возможно, но в рамках рабочих нормальных отношений, — то чувства обиды не будет.
Нужно кооперироваться и уважать чужие решения. Даже если кажется, что они неверны.
К сожалению, такая ситуация очень частая в IT. Мало кому из руководителей удается зажечь глаза у своих девов, и при этом зажечь и в пользу интересов дела. Это скорее исключение и искусство. И очевидно, что владелец сайта был полной противоположностью таких людей.
Кооперироваться банально невыгодно. Да, люди не хотят быть плохими, но шаг за шагом, сами того не замечая, начинают. В данном конкретном случае «уважать чужие решения» == «искать баги в чужом коде целыми днями» && «изучать устаревшие технологии». Зачем? За это не будут больше платить, и не дадут долю в бизнесе.
Есть совсем упоротые, которые подвызываются на фриланс либо удаленку параллельно с основной работой, и две, а то и три ЗП одновременно получают (и при этом ловят намного больший кайф от того, как поимели систему и дебилов менеджеров, чем от процесса траты трех ЗП), но большинство просто начинает подменять нужные задачи интересными, поучивать технологии в рабочее время, продавать ненужные усложнения бизнесу. Это повсеместная проблема, и лично для себя я сделал вывод, что системно она не решаема. Или нужен маг, который зажгет глаза (но на поток ты хантинг магов не поставишь, а чаще появляются зажигатели глаз, но в невыгодном для бизнеса направлении — приходит главный архитектор, и говорит «сейчас есть мегатренд — новая технология. Давайте разбираться, и перепишем все на ней»), или просто бизнес должен признать, что производство кода имеет запредельный % брака, и вбрасывать больше ресурсов.
Кооперироваться банально невыгодно. Да, люди не хотят быть плохими, но шаг за шагом, сами того не замечая, начинают. В данном конкретном случае «уважать чужие решения» == «искать баги в чужом коде целыми днями» && «изучать устаревшие технологии». Зачем? За это не будут больше платить, и не дадут долю в бизнесе.
Есть совсем упоротые, которые подвызываются на фриланс либо удаленку параллельно с основной работой, и две, а то и три ЗП одновременно получают (и при этом ловят намного больший кайф от того, как поимели систему и дебилов менеджеров, чем от процесса траты трех ЗП), но большинство просто начинает подменять нужные задачи интересными, поучивать технологии в рабочее время, продавать ненужные усложнения бизнесу. Это повсеместная проблема, и лично для себя я сделал вывод, что системно она не решаема. Или нужен маг, который зажгет глаза (но на поток ты хантинг магов не поставишь, а чаще появляются зажигатели глаз, но в невыгодном для бизнеса направлении — приходит главный архитектор, и говорит «сейчас есть мегатренд — новая технология. Давайте разбираться, и перепишем все на ней»), или просто бизнес должен признать, что производство кода имеет запредельный % брака, и вбрасывать больше ресурсов.
Я уже написал постом ниже — второй разработчик обошелся компании в 2400000 рублей минимум, Вы уверены что это было оптимальное расходование средств?
Любой бизнес это стратегия — как при ограниченных ресурсах достигать максимальных результатов. Переписывание проекта — это ставка на долгосрочный результат, может быть лучше было бы решать коротко срочные задачи?
Любой бизнес это стратегия — как при ограниченных ресурсах достигать максимальных результатов. Переписывание проекта — это ставка на долгосрочный результат, может быть лучше было бы решать коротко срочные задачи?
UFO just landed and posted this here
Интересно, что о самом важном автор и не написал. Что мне (пользователю) нужно от сайта недвижимости? Нужна база. Если я уверен, что все предложения в городе есть на одном сайте — я буду постоянно пользоваться только этим сайтом. И всем остальным советовать. И агенты будут ориентироваться именно на этот сайт.
Иными словами, вместо SEO и оптимизации сайта надо было заниматься привлечением клиентов. Одна точка подачи объявлений на город? Вы не понимаете, насколько это неудобно. Нет преимуществ подавшим объявление в поиске на сайте? Опять неудобно. Нет оплаты через инет? Опять неудобно.
Вот потихоньку ваших клиентов и переманили те, где было удобно.
Иными словами, вместо SEO и оптимизации сайта надо было заниматься привлечением клиентов. Одна точка подачи объявлений на город? Вы не понимаете, насколько это неудобно. Нет преимуществ подавшим объявление в поиске на сайте? Опять неудобно. Нет оплаты через инет? Опять неудобно.
Вот потихоньку ваших клиентов и переманили те, где было удобно.
Агентствами объявления в БН подаются в электронном виде более 20 лет. Может, они в основном на них ориентировались?
Вот в этом и ошибка. Я, как просто пользователь, ищу там, где есть всё. Агентству нетрудно подать и на 5 и на 10 сайтов. А частник — подает в 1-2 места, при этом цена у частника ниже (нет или мал агентский процент). Так что искать я буду там, куда ушли частники. И агентства уходят туда, куда идут частники.
Никогда не слышал про БН, если честно.
Мы — разработчики и могли только отпимизировать сайт. У нас были и плюшки для ручного размещения, и оплата через интернет, и бонусы для клиентов. А вот привлечением занимались периодически и малоуспешно.
Мы — разработчики и могли только отпимизировать сайт. У нас были и плюшки для ручного размещения, и оплата через интернет, и бонусы для клиентов. А вот привлечением занимались периодически и малоуспешно.
UX никто не отменял. Найдите на БН список способов оплаты. Мне за 3 минуты это не удалось. Это терпимо, лишь когда он был номером 1 в Питере.
А проблемы ведь куда глубже. К примеру, в Украине лидер рынка аггрегаторов недвижимости — lun.ua. Посмотрите, как там все устроено, как групируются дубликаты квартир, которые риэлторы тщательно плодят, специально находя дыры в алгоритмах, и стараясь таки создать дубликат (там серьезные матмодели, специально разработанные математиками для этого сайта, ML/AI на видеокартах), как определяется владелец/риэлтор, как работает мобильная версия сайта, сколько сайтов парсится (и не факт, что все они по воле владельца сайта). Как работает поиск — вы смогли бы на своем стеке технологий с такой же скоростью находить все квартиры в видимой части карты?
Я это все к тому, что увы, при всем уважении к автору, ну не сделать даже имея полную поддержку бизнеса и дрим тим из 5 фулл-стек синиор разрабов, захват рынка. Пользователи привыкают к массе мелких плюшек. Пользователи хотят актуальную базу данных с мгновенным парсингом даже тех агенств, которые активно защищаются от ботов-парсеров. Пользователи хотят того, на что надо масса человекочасов, даже если все писать с первого раза и без багов.
Я это все к тому, что увы, при всем уважении к автору, ну не сделать даже имея полную поддержку бизнеса и дрим тим из 5 фулл-стек синиор разрабов, захват рынка. Пользователи привыкают к массе мелких плюшек. Пользователи хотят актуальную базу данных с мгновенным парсингом даже тех агенств, которые активно защищаются от ботов-парсеров. Пользователи хотят того, на что надо масса человекочасов, даже если все писать с первого раза и без багов.
Все понятно. Владелец решил заняться SEO-магией. Надо было еще святой водой кропить серверА и прокалывать волосяные куклы конкурентов.
Это генально. Вместо решения актуальных задач — тайком переписывали проект, сил не хватало и наняли второго, ведь очень много работы и не получается тайком в одни руки переписывать проект.
А потом оказалось, что нужные задачи не решены, зато есть сверкающая отполированная платформа, которая не способна вытащзить компанию, потому что владельцу нужен не переписанный проект, а проект соответствующий его требованиям, которого нет, потому что вместо решения поставленных задач перепиливалась платформа тайком. Да, да, виноват конечно руководитель.
Это генально…
А потом оказалось, что нужные задачи не решены, зато есть сверкающая отполированная платформа, которая не способна вытащзить компанию, потому что владельцу нужен не переписанный проект, а проект соответствующий его требованиям, которого нет, потому что вместо решения поставленных задач перепиливалась платформа тайком. Да, да, виноват конечно руководитель.
Это генально…
Зато автор набрался опыта, изучил технологии и теперь будет использовать этот опыт (а возможно и какие-то нараборки со старого портала) на своём новом проекте по недвижимости.
Но это все же не совсем этично — во время оплаченное работодателем пилить свой проект
Я не говорил, что я такое поддерживаю. Просто для проекта результат оказался печальным, а для автора — относительно неплохим. Впрочем, по имеющимся данным сложно сказать насколько действительно действия автора сказались на судьбе портала.
Тоже есть вопросы к качеству такого опыта. По сути, это «обучение без учителя» — так, как не было человека, который бы смотрел на код и архитектурные решения, и говорил бы хорошо/плохо. Такие люди (которые могут в одиночку создать продукт без лидов и архитектов) реально круты, но есть много но, которые связаны с работой в команде и руководством командами)
UFO just landed and posted this here
Красивая упаковка = 45% успеха
Бабло в рекламу = 45% успеха
Архитектура и код = 10% успеха
Как то так
Бабло в рекламу = 45% успеха
Архитектура и код = 10% успеха
Как то так
Моё мнение — для своего роста выбрали не ту компанию. Если Вы разрабатывали продукт тайно от руководства, значит, компании это было не нужно. Компания тупо загибалась. Ваша точка зрения, что загибалась из-за низкого качества продукта — оказалось не совсем верное.
Я видел, как в одной крупной корпорации не приветствовали собственные разработки. Все централизовано закупалось. Так вот, разработчиков с треском уволили, с трудовыми комиссиями, с фабрикованием ложных трудовых характеристик, с подставами с опозданиями, и т.д., потому что вдруг выяснилось, что разработанное условно бесплатное ПО по функционалу и качеству на голову превышало возможности дорогостоящего закупаемого ПО, с которого начальники имели профит в виде отката.
Я видел, как в одной крупной корпорации не приветствовали собственные разработки. Все централизовано закупалось. Так вот, разработчиков с треском уволили, с трудовыми комиссиями, с фабрикованием ложных трудовых характеристик, с подставами с опозданиями, и т.д., потому что вдруг выяснилось, что разработанное условно бесплатное ПО по функционалу и качеству на голову превышало возможности дорогостоящего закупаемого ПО, с которого начальники имели профит в виде отката.
В 2008 древнем году старая платформа на костылях вытягивала 1М посетителей.
В 2014 году посетителей стало меньше в 3 раза, но старая платформа все равно перестала справляться с нагрузкой. Сервер устал? ;)
Программистов понять легко, они старались сделать как лучше. Но если бы они и не ударились в тайное причинение добра, а смирно выполняли все хотелки руководства — результат был бы тот же.
В 2014 году посетителей стало меньше в 3 раза, но старая платформа все равно перестала справляться с нагрузкой. Сервер устал? ;)
Программистов понять легко, они старались сделать как лучше. Но если бы они и не ударились в тайное причинение добра, а смирно выполняли все хотелки руководства — результат был бы тот же.
Не совсем согласен, можно было бы сэкономить на ЗП одного из программистов даже при ЗП в 60к (хотя думаю что выше) — это затраты минимум 100к в месяц для фирмы. Второй программист работал насколько я понимаю 2 года — следовательно можно было сэкономить 2 400 000 рублей, деньги не очень большие — но все же.
То есть если предположить, что исход был бы такой же — самореализация автора как клевого программиста переписавшего всё в идеальный не кому не нужный код обошлась фирме которая и так загибается в 2400000 рублей.
То есть если предположить, что исход был бы такой же — самореализация автора как клевого программиста переписавшего всё в идеальный не кому не нужный код обошлась фирме которая и так загибается в 2400000 рублей.
Если фирма уже загибается — зарплата одного человека никак на этот процесс не влияет. Можно было бы не нанимать еще одного программиста… Протянули бы на месяц больше. Если в штате только 2 программиста и директор — на полгода ;) Можно было бы строго напрячь автора не заниматься отсебятиной, а все усилия направить в поддержку старой системы… Еще полгода…
Всегда улыбало, когда люди, пришедшие в бизнес из комсомола или программирования видят в SEO волшебную палочку, которая прям завтра сделает их проект мегапопулярным, а их миллионерами стоит только SEO оптимизироваться и клиент попрет и оптом и в розницу… За 20 лет, что я занимаюсь маркетингом, ни разу еще не видел, чтобы SEO хоть кому-то помогло. Если в команде от босса и до последний уборщицы люди не понимают, кто их клиент и какую ценность они создают для клиентов своим продуктом/сервисом, то, как бы, это все пустая трата времени и сил. Помимо поисковиков есть еще миллион способов продвижения интернет ресурсов, используя другие каналы, которые для многих проектов/ресурсов даже более эффективны, чем весь бюджет на SEO, включая зарплаты специалистов. Все ведь можно в деньгах посчитать. Обидно за профессию, никто клиентской аналитикой не занимается, SEO и А/B тестирование заменило здравый смысл… Печально :(
В золотые времена этого портала SEO действительно работало. Возможно, оно не способно удержать посетителя и заставлять возвращаться снова и снова, но в качестве средства первичного нагона трафика оно было очень даже неплохо. А что ещё надо порталу, который живёт продажей своего трафика? Потом мир стал меняться, но владелец ресурса предпочёл действовать по-старинке.
Следующая статья автора будет ещё большим пиаром "новой супер платформы".
Так, ладно, работа нужна?
Да денег нет, но вы держитесь! И клиентов нет пока =)
Да дружище ты прав в выводах.
Я заметил такую вещь, что у программистов своеобразный склад ума и взглядов, и им в команду всегда требуются специалисты другого уровня, как стратегический менеджмент, маркетинг и т.п.
Читал твою статью чуть ли не со слезами на глазах. Очень печально что такой труд умер. К сожалению, а может и к радости — множество проектов умирает по этой причине.
Создавая портал — нужно понимать такую вещь в первую очередь — сайт (любой «полезный» кстати) — это не кусочек кода с «техником» — это такая же функциональная фирма как и любая другая офисная, так же требует «техничку», директора, менеджера, маркетолога, и «водителя» — вот многие об этом забывают.
В твоей статье меня порадовал твой профессионализм и усидчивость — это высокая ценность в твоей среде, береги ее и развивай. И ради бога не трать себя на «пустые» компании.
Желаю тебе найти перспективный проект с перспективной командой.
Я заметил такую вещь, что у программистов своеобразный склад ума и взглядов, и им в команду всегда требуются специалисты другого уровня, как стратегический менеджмент, маркетинг и т.п.
Читал твою статью чуть ли не со слезами на глазах. Очень печально что такой труд умер. К сожалению, а может и к радости — множество проектов умирает по этой причине.
Создавая портал — нужно понимать такую вещь в первую очередь — сайт (любой «полезный» кстати) — это не кусочек кода с «техником» — это такая же функциональная фирма как и любая другая офисная, так же требует «техничку», директора, менеджера, маркетолога, и «водителя» — вот многие об этом забывают.
В твоей статье меня порадовал твой профессионализм и усидчивость — это высокая ценность в твоей среде, береги ее и развивай. И ради бога не трать себя на «пустые» компании.
Желаю тебе найти перспективный проект с перспективной командой.
«Я не мог так сказать, это же абсурд»
Первое правилобойцовского клуба в ИТ — всегда пишите протокол.
Первое правило
UFO just landed and posted this here
Sign up to leave a comment.
Как мы создали технологичный продукт и провалились на дно